W3C home > Mailing lists > Public > www-tag@w3.org > December 2014

Re: [url] Requests for Feedback (was Feedback from TPAC)

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 2 Dec 2014 16:12:59 +1100
Cc: public-ietf-w3c@w3.org, www-tag@w3.org
Message-Id: <D504FED5-8F28-4F4C-89B8-949AE9B5C6B5@mnot.net>
To: Sam Ruby <rubys@intertwingly.net>
Hi Sam,

> On 1 Dec 2014, at 3:30 am, Sam Ruby <rubys@intertwingly.net> wrote:
> My understanding (see forwarded message below) was that the IETF and W3C TAG were going to issue statements providing input to the evolution of the URL Standard in mid-November.  As November is now drawing to a close, can I get an update on the status of this?

I've discussed this with Barry, the responsible AD, who has said he's going to hold the document until this and another (unrelated) situation become more clear (and perhaps beyond) -- see:

> Additionally, the effort to merge my parser work with the remainder of the URL standard is now at a point where I would like to encourage wider review -- either by individuals or by groups:
> https://specs.webplatform.org/url/webspecs/develop/
> I'd suggest that the first three sections (namely, 'Goals', 'URLs', and 'Authoring Requirements') would be of particular interest to the IETF and TAG, but I welcome input on all sections.
> My preferred method if input is GitHub pull requests:
> https://github.com/webspecs/url/pulls
> Alternate methods of input (including discourse itself) and other related links can be found here:
> http://discourse.specifiction.org/t/about-the-url-category/691
> Finally, input on the following bug would be appreciated:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25946

Like Domenic, I strongly support these goals; I've done it in person, but I also want to publicly thank you for grasping the nettle -- one that has stung many a person.


> - Sam Ruby
> -------- Forwarded Message --------
> Subject: [url] Feedback from TPAC
> Date: Fri, 31 Oct 2014 17:01:50 -0700
> From: Sam Ruby <rubys@intertwingly.net>
> To: WhatWG <whatwg@whatwg.org>
> 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

Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 2 December 2014 05:13:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:08 UTC