rfc2231-in-http: token characters, was: FYI: I-D Action:draft-reschke-rfc2231-in-http-08.txt

[Julian Reschke <[e-mail]>]

Julian Reschke wrote:
> Hi,
> 
> I have updated the draft with feedback I got during the informal "last 
> call" that ended yesterday (I added a statement about the relation RFC 
> 2388, and added information about existing implementations).
> 
> See diffs at 
> <http://tools.ietf.org/rfcdiff?url2=draft-reschke-rfc2231-in-http-08.txt>.
> 
> Next, I'll send a publication request to the Apps Area Directors.
> 
> Best regards, Julian
> ...

In the meantime it was discovered that the allowed characters inside 
RFC2231-encoded parameter values differ from what RFC 2231 specifies.

There are two reasons for that:

1) token in RFC 2616 disallows "{" and "}", while token in MIME (RFC 
2231 and RFC 2045) does not; thus these are disallowed in 
rfc2231-in-http as well, and

2) I was disallowing more characters then I wanted to, and also allowed 
":" which shouldn't have been there.

For 1) I have added an explanation, simply pointing out the difference 
(<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.tokengrammar>)

For 2), I have now changed the ABNF so that all characters from 
RFC2616's token, except for the special characters used in 2231 ("*", 
"%", "'"), are allowed. 
(<http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-latest.html#rfc.issue.attrcharvstoken>)

I'm planning to submit a new draft early next week, and then to get to 
IETF LC soonish.

Best regards, Julian

PS: also I have started work on tools that allow sanity checks on ABNF 
productions, such as "set A is expected to be identical to set (B \ C)", 
so things like that can be checked more easily in the future.