bcc: WebApps, IETF, TAG in the hopes that replies go to a single place.
- - -
I took the opportunity this week to meet with a number of parties
interested in the topic of URLs including not only a number of Working
Groups, AC and AB members, but also members of the TAG and members of
the IETF.
Some of the feedback related to the proposal I am working on[1]. Some
of the feedback related to mechanics (example: employing Travis to do
build checks, something that makes more sense on the master copy of a
given specification than on a hopefully temporary branch. These are not
the topics of this email.
The remaining items are more general, and are the subject of this note.
As is often the case, they are intertwined. I'll simply jump into the
middle and work outwards from there.
---
The nature of the world is that there will continue to be people who
define more schemes. A current example is
http://openjdk.java.net/jeps/220 (search for "New URI scheme for naming
stored modules, classes, and resources"). And people who are doing so
will have a tendency to look to the IETF.
Meanwhile, The IETF is actively working on a update:
https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
They are meeting F2F in a little over a week[2]. URIs in general, and
this proposal in specific will be discussed, and for that reason now
would be a good time to provide feedback. I've only quickly scanned it,
but it appears sane to me in that it basically says that new schemes
will not be viewed as relative schemes[3].
The obvious disconnect is that this is a registry for URI schemes, not
URLs. It looks to me like making a few, small, surgical updates to the
URL Standard would stitch all this together.
1) Change the URL Goals to only obsolete RFC 3987, not RFC 3986 too.
2) Reference draft-ietf-appsawg-uri-scheme-reg in
https://url.spec.whatwg.org/#url-writing as the way to register schemes,
stating that the set of valid URI schemes is the set of valid URL schemes.
3) Explicitly state that canonical URLs (i.e., the output of the URL
parse step) not only round trip but also are valid URIs. If there are
any RFC 3986 errata and/or willful violations necessary to make that a
true statement, so be it.
That's it. The rest of the URL specification can stand as is.
What this means operationally is that there are two terms, URIs and
URLs. URIs would be of a legacy, academic topic that may be of
relevance to some (primarily back-end server) applications. URLs are
most people, and most applications, will be concerned with. This
includes all the specifications which today reference IRIs (as an
example, RFC 4287, namely, Atom).
My sense was that all of the people I talked to were generally OK with
this, and that we would be likely to see statements from both the IETF
and the W3C TAG along these lines mid November-ish, most likely just
after IETF meeting 91.
More specifically, if something along these lines I describe above were
done, the IETF would be open to the idea of errata to RFC3987 and
updating specs to reference URLs.
- Sam Ruby
[1] http://intertwingly.net/projects/pegurl/url.html
[2] https://www.ietf.org/meeting/91/index.html
[3] https://url.spec.whatwg.org/#relative-scheme
