RE: URL work in HTML 5

I think there was a group willing to consider the redefinition of URLs in HTML5 as a local anomaly within HTML, in a way that didn't really affect any other format or application.

However, registerProtocolHandler makes it clear that HTML activities affect the entire use of URIs and IRIs within anywhere in the system.

After a sucessful registerProtocolHandler("mailto", ....)  then every mailto: URI is expected to work differently.

Unfortunately, http://tools.ietf.org/html/rfc6068 RFC 6068  asserts:

"The 'mailto' URI has unusual semantics because resolving such a URI
   does not cause an immediate interaction with a server."

Unfortunately, after the call
navigator.registerProtocolHandler("mailto",
                                  "https://mail.google.com/mail/?extsrc=mailto&url=%s",
                                  "Gmail");

This is no longer true.  mailto:www-tag@w3.org immediately turns into https://mail.google.com/mail/?extsrc=mailto&url=mailto:www-tag@w3.org which then immediately interacts with Google.

So RFC 6068 is incorrect, and systems which relied on the assurance within it (that resolving a mailto URI results in no server interactions) must be reexamined for their security properties (or else such systems must disallow installation of browsers which properly implement registerProtocolHandler as advertised.)

"Who cares what the dozens of books on my bookshelf say about the term "

This is just the price of progress.  There are dozens of books that talk about XHTML too.  I want to focus on the functional changes which break existing systems, and not get distracted by the provocative "willful violations" and terminology games.

Larry


From: Roy T. Fielding [mailto:fielding@gbiv.com]
Sent: Monday, September 24, 2012 2:44 PM
To: Noah Mendelsohn
Cc: W3C TAG
Subject: Re: URL work in HTML 5

On Sep 24, 2012, at 7:00 AM, Noah Mendelsohn wrote:


www-tag readers may be interested in the attached e-mail which links to one from from Anne van Kesteren [1], which was relayed to the URI mailing list by Julian Reschke. The e-mail suggests that

> The plan is to obsolete the RFCs. But yes, I will add some references

> in the Goals section most likely. Similar to what has been done in the

> DOM Standard.
Julian raises the concern that RFC 3986 is a Full (and widely deployed) Standard. I believe this discussion is in relation to [2], which contains the following related text:

-------------

2.6 URLs

This specification defines the term URL<http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url>, and defines various algorithms for dealing with URLs, because for historical reasons the rules defined by the URI and IRI specifications are not a complete description of what HTML user agents need to implement to be compatible with Web content.

Note: The term "URL" in this specification is used in a manner distinct from the precise technical meaning it is given in RFC 3986. Readers familiar with that RFC will find it easier to read this specification if they pretend the term "URL" as used herein is really called something else altogether. This is a willful violation<http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#willful-violation> of RFC 3986. [RFC3986]<http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#refsRFC3986>
--------------

Noah

[1] http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Sep/0297.html
[2] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html


Yes, it is truly remarkable that otherwise functioning human beings
are willing to go so out of the way to redefine "URL" to mean what
most people call a reference, rather than simply admit that they were
using the wrong word inside the clique of whatwg.

Hence, the value of href is now a URL, not a hypertext reference, and
the value of src is a URL, not a source reference.  Who cares what the
dozens of books on my bookshelf say about the term?

BTW, did you know that "" is a URL?

....Roy