mailto: URI/IRI scheme and registerProtocolHandler (was: Re: URL work in HTML 5)

Hello Larry, others,

On 2012/09/25 11:29, Larry Masinter wrote:
> 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, 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",
>                                    "",
>                                    "Gmail");
> This is no longer true. immediately turns into 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.)

This is a very valid point. I have submitted a new version of 
draft-duerst-mailto-eai where I added text discussing this, both to the 
semantics section (where the above cited text can be found) and to the 
security considerations section. You can find the draft at any of the 
following locations. The first three are 'internationalized' versions, 
the last two old style US-ASCII only versions:

The texts in question are as follows:

In Semantics and Operations:

             The 'mailto' URI/IRI has unusual semantics because resolving
    such a URI/IRI does not necessarily cause an immediate interaction
    with a server.  Instead, the client creates a message to the
    designated address with the various header fields set as default.
    The user can edit the message, send the message unedited, or choose
    not to send the message.

    Note that with the introduction of the possibility to register
    handlers of URI/IRI schemes to web applications, there is no longer a
    guarantee that the resolution of a 'mailto' URI/IRI is purely local.
    Registering a web mail service as a handler of 'mailto' URIs/IRIs
    means that the creation of a message to the designated address is
    done with the help and knowledge of that web mail service.

In Security Considerations:

    Also, if a web mail service is registered as a handler of 'mailto'
    URIs/IRIs, this means that the creation of a message to the
    designated address is done with the knowledge of that web mail
    service, even if the message is actually never sent.

This text was written rather quickly, so I'm sure it can be improved, 
please provide comments.

Regards,   Martin.

> "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 []
> 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<>, 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<>  of RFC 3986. [RFC3986]<>
> --------------
> Noah
> [1]
> [2]
> 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

Received on Tuesday, 25 September 2012 10:38:05 UTC