application/x-www-form-urlencoded

Hi all,

I was disappointed to see that my February suggestions for fixing XForms 1.0's 
botched revamp of application/x-www-form-urlencoded did not not make it into 
the XForms 1.0 2nd ed. Proposed Edited Recommendation. I am wondering what
happened; I never heard anything about it.

In February 2005 [1] I had asked that consideration be given to an erratum
to fix a couple of issues with section 11.6 of the XForms 1.0 spec. There
was a major issue and a minor one.

The minor one, which I don't really care about anymore, was just the
phrasing of the reference to the now-superseded RFC 2396. It's not worth
pursuing; the intent of the current wording is clear enough.

The major one is that it uses the term "non-ASCII and reserved" where it 
should use "non-ASCII and non-unreserved".

The only characters that are safe to leave in their raw form in this media 
type, or in any URI, are those in the "unreserved" set:
A-Z, a-z, 0-9, ~, -, _, and period.

The "reserved" set is for characters that have (or may, in some cases) have
special meaning. The set, as of RFC 3986, consists of:
!, *, ', (, ), ;, :, @, &, =, +, $, /, ?, %, #, [, ], and comma.

When you say "non-ASCII and reserved" are the ones that need to be converted 
to UTF-8 and percent-encoded, it is implicit that the unreserved set is safe 
to leave as-is. But, aside from space, LF and CR, you have not accounted for
a number of characters that are in ASCII, but are not in the reserved or
unreserved sets.

This would most easily be addressed by just changing the "reserved" to
"non-unreserved" in the specification. This would restore the intended
behavior to match previous specifications and implementations.

Thanks,

Mike

[1] http://lists.w3.org/Archives/Public/www-forms/2005Feb/0028.html
    (please forgive my misspelling of 'superseded' therein)

Received on Saturday, 8 October 2005 22:08:41 UTC