On 11/01/2014 07:18 PM, Barry Leiba wrote:
Thanks, Sam, for this great summary -- I hadn't taken notes, and was
hoping that someone who was (or who has a better memory than I) would
post something.
One minor tweak, at the end:
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.
Errata to 3986, that is, not 3987. After this, 3987 will be
considered obsolete (the IESG might move to mark it "Historic", or
some such).
Thanks for the correction. I did indeed mean errata to 3986.
- Sam Ruby
Barry, IETF Applications AD
On Fri, Oct 31, 2014 at 8:01 PM, Sam Ruby <ru...@intertwingly.net> wrote:
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
