[whatwg] New URL Standard

[Anne van Kesteren]

On Tue, Sep 25, 2012 at 8:20 PM, David Sheets <kosmo.zb at gmail.com> wrote:
> On Tue, Sep 25, 2012 at 8:03 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> FWIW, given that browsers happily do requests to servers with
>> characters in the URL that are "invalid" per the RFC (they are not URL
>> escaped) and servers handle them fine I think we should make the
>> syntax more lenient. E.g. allowing [ and ] in the path and query
>> component is fine I think.
>
> I believe this would introduce ambiguity for parsing URI references.
> Is "[::1]" an authority reference or a path segment reference?

Path.


>> As for the question about why not build this on top of RFC 3986. That
>> does not handle non-ASCII code points. RFC 3987 does, but is not a
>> suitable start either. As shown in http://url.spec.whatwg.org/ it is
>> quite trivial to combine parsing, resolving, and canonicalizing into a
>> single algorithm (and deal with URI/IRI, now URL, as one).
>
> Composition is often trivial but unenlightening. There is necessarily
> less information in a partially evaluated function composition than in
> the functions in isolation.
>
> Defining a formal language accurately and in a broadly understandable
> manner is nontrivial. Your task is nontrivial.

I have no idea what you are talking about.


> What is the acceptable trade-off between (y)our hassle and the time of
> technologists in the coming decades? Will you make it easier or harder
> for them to reconcile WHATWG-URL and Internet Standard 66 (RFC 3986)?

I'm not sure why I should care about STD 66. It is inaccurate, does
not match implementations, and cannot be used to write new
implementations that want to be compatible with content and services
on the web. I am tackling those problems, and writing them down in a
way we have written standards for over eight years now, which thus far
has been successful.

(Obviously STD 66 is a document many people value, but these people
generally have not looked at the particulars or written software that
deals with Location headers whose values contain spaces, etc. assuming
they have a "correct" STD 66 implementation to begin with. If there is
a document that addresses URLs on the web better, they will use that
instead.)


-- 
http://annevankesteren.nl/