[url] Feedback from TPAC

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

Received on Saturday, 1 November 2014 00:02:16 UTC