On 11/02/2014 02:32 PM, Graham Klyne wrote:
On 01/11/2014 00:01, Sam Ruby wrote:
3) Explicitly state that canonical URLs (i.e., the output of the URL
not only round trip but also are valid URIs. If there are any RFC
and/or willful violations necessary to make that a true statement, so
It's not clear to me what it is that might be "willfully violated".
Specifically, I find the notion of "relative scheme" in  to be, at
best, confusing, and at worst something that could break a whole swathe
of existing URI processing. I don't know which, as on a brief look I
don't understand what  is trying to say here, and I lack time (and
will) to dive into the arcane style used for specifying URLs.
First, I'm assuming that by , you mean
Second, I have no idea how a specification that essentially says "here's
what a set of browsers, languages, and libraries are converging on to
convert URLs into URIs can break URIs.
Third, here's a completely different approach to defining URLs that
produces the same results (modulo one parse error that Anne agrees
should changed in be in the WHATWG spec):
If for some reason you don't find that to be to your liking, I'll be
glad to try to meet you half way. I just need something more to go on
I think there may be a confusion here between syntax and
interpretation. When the term "relative" is used in URI/URL context, I
immediately think of "relative reference" per RFC3986. I suspect what
is being alluded to is that some URI schemes are not global in the
idealized sense of URIs as a global namespace - file:///foo dereferences
differently depending on where it is used - the relativity here being in
the relation between the URI/URL and the thing identified, with respect
the the where the URI is actually processed.
If you find it confusing, perhaps others will too. Concrete suggestions
on what should be changed would be helpful.
To change the syntactic definition of "relative reference" to include
things like file: and ftp: URIs would cause all sorts of breakage, and
require significant updating of the resolution algorithm in RFC3986
(more than would be appropriate for a mere "erratum", IMO). I'm hoping
this is not the kind of willful violation that is being contemplated here.
Note in reformulated grammar, file is no longer treated the same as
other types of relative references. I am not wedded to any of those
terms, if you suggest better ones I'll accommodate.
If errata can be produced expeditiously for RFC3986, then there
shouldn't be any need for willful violations.