Re: [apps-discuss] RFC6454 "the web origin concept" obsoleted?

[John C Klensin <[e-mail]>]

Hi.

One, possibly-useful addition to what Daniel has written below.
According to RFC 3986, but completely ignored or rejected by the
WHATWG URL spec, one of the reasons the terminology was switched
to focus on the term "URI" is that there are URIs that are not
URLs or even "locators" but "names".  In retrospect, that switch
might have been a mistake but it affects today's reality.  In
particular, the most important name-type URIs are URNs (or,
because there is even more confusion, more precisely URIs of
scheme "urn:").  URNs of that variety (specified by RFC 2141)
never use "://", a typical one might look like
"urn:ietf:rfc:3986" or "urn:issn:2070-1721".

Independent of the [URL] document, many people have argued
strongly that, for example, the piece of HTML that allows URLs
in <a> elements is required to accept [generalized] URIs (not
just HTTP and HTTPS URLs) and process them in some way, making
the above distinctions either important or troublesome,
depending on how one looks at the issue.  "Argued strongly" is
not intended as any disrespect -- it is hard to read the HTML
specs in any other way.

The URNBIS WG is in the process of updating RFC 2141 and some
related specs to allow more capabilities and to better reflect
contemporary practice and requirements.  I'd recommend its
mailing list, discussions, and documents to anyone interested in
seeing another direction for where these discussions lead.

best,
    john


--On Monday, July 18, 2016 23:00 +0200 Daniel Stenberg
<[e-mail]> wrote:

> On Mon, 18 Jul 2016, [e-mail] wrote:
> 
>> * Are the changes to RFC3986 & RFC3987 evidenced in [URL]
>> widely applicable  to all URL-utilizing specs and if so, do
>> we obsolete them and point to  [URL], or backport the changes
>> to RFC3986bis & RFC3987bis? Or do something  else, or do
>> nothing?
> 
> The [URL] spec is mostly followed by browsers while the rest
> of the URL parsing world is all over the place but very few
> non-browsers implement the [URL] spec and instead do various
> mixes of what the RFCs say and the browsers do. I blogged
> about this exact issue a short while ago [1] after having
> realized the [URL] spec says eight thousand slashes in a HTTP
> URL is fine and should be parsed.
> 
> I personally am not a fan of neither the [URL] spec style (I
> find it very hard to read), how it is being written or what it
> says a URL can look like. But I know I get a lot of objections
> and "web compatibility" arguments thrown at me when I say so...
> 
> So the RFCs are currently lacking a lot when it comes to
> parsing modern URLs, but the [URL] spec is not even trying to
> make a spec for an entire web infrastructure so it isn't a
> generic solution either. I don't have a good answer for where
> we should go from here.
> 
> [1] =
> https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/