No apology needed, thanks for forwarding it. I think we have a need to
publicise the existence of this problem.
> > That's the real problem. I used that syntax because that's
> >what was in use elsewhere in the Web. Red alert? If you say so.
For the specific problem (of using an & as a field separator in the
argument portion of a URL) how do we best explain that although that
syntax may appear to be used elsewhere, these arguments after the "?"
in URLs are not part of HTML. On the contrary, they are arguments to be
passed off to an external process, which means some people will need to
be able to encode arbitrary text in them.
> The problem is that folks have been lazily slinging strings around
> in various context without taking encoding considerations into
> account.
We do still have the 1-browser-centric approach of most users: "it works
when _I_ do it, so it _must_ be right".
> 1. Encode the string as a URL "word" by replacing all occurences
> of "reserved" characters ':', '/', '?', etc. and whitespace
> by %xx equivalents.
Do you have the pointer to where these reserved characters are listed?
Would browser authors be prepared to unify their parsing or non-parsing of
these strings?
///Peter