RE: '#' in mailto URIs

Martin Dürst wrote:

> The text that I might put in (if we think we need some) is:
> 
>  >>>>
> Note that this specification, like any URI scheme specification, does 
> not define syntax or meaning of a fragment identifier, because these 
> depend on the media type of the retrieved resource. In the currently 
> known usage scenarios, a 'mailto' URI does not serve to retreive a 
> resource with a media type. Therefore, fragment identifiers are 
> meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored 
> upon resolution.
>  >>>>

So, this reminds me of an aspect of RFC 3986 that I find surprising.  It 
says [1] :

>    The fragment identifier component of a URI allows indirect
>    identification of a secondary resource by reference to a primary
>    resource and additional identifying information.  The identified
>    secondary resource may be some portion or subset of the primary
>    resource, some view on representations of the primary resource, or
>    some other resource defined or described by those representations.  A
>    fragment identifier component is indicated by the presence of a
>    number sign ("#") character and terminated by the end of the URI.
> 
>       fragment    = *( pchar / "/" / "?" )
> 
>    The semantics of a fragment identifier are defined by the set of
>    representations that might result from a retrieval action on the
>    primary resource.  The fragment's format and resolution is therefore
>    dependent on the media type [RFC2046] of a potentially retrieved
>    representation, even though such a retrieval is only performed if the
>    URI is dereferenced.  If no such representation exists, then the
>    semantics of the fragment are considered unknown and are effectively
>    unconstrained.  Fragment identifier semantics are independent of the
>    URI scheme and thus cannot be redefined by scheme specifications.


What surprises me in the above is the specific reference to media types. 
If I hadn't read the above, I would have assumed that the Web worked 
something like this:

* Resources are identified with URIs, each of which has a scheme
* For some such URIs, protocols such as HTTP can be used to retrieve 
representations of the resource
* For the representation to be usable, it will typically be necessary for 
the protocol to convey (explictly or implicitly) the type of each such 
representation.  In the case of HTTP, typing is done using media types 
[RFC 2046], but other protocols may use different typing schemes.

The quote form RFC 3986 seems to imply that media types are the only 
supported typing mechanism for media types, regardless of the protocol 
used for retrieval.  I understand that we are also trying to achieve a 
situation in which fragment identifier resolution is defined with respect 
to the type of the representation, not the URI scheme or retrieval 
protocol.  Still, I would have thought it should say something like:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the
primary resource.  The fragment's format and resolution is therefore 
dependent on >the type< of a potentially retrieved representation >(media 
type [RFC2046] in the case of HTTP retrievals)<, even though such a 
retrieval is only performed if the URI is dereferenced.

Martin: given what's in 3986, your specific reference to media type is OK, 
I guess, but it still feels strange to me in the context of mailto.  I 
also find it somewhat more appropriate to speak of retrieving 
representations than retrieving resources.  Therefore, I wonder whether it 
might be a little better to say (changes marked with >...<):

---Proposed---
Note that this specification, like any URI scheme specification, does 
not define syntax or meaning of a fragment identifier, because these 
depend on the >type of a retrieved representation<. In the currently 
known usage scenarios, a 'mailto' URI >cannot be used to retreive
such representations<. Therefore, fragment identifiers are meaningless,
SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored upon
resolution.
---End Proposed---

Noah

[1] http://www.ietf.org/rfc/rfc3986.txt


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Larry Masinter <masinter@adobe.com>
Sent by: uri-request@w3.org
10/14/2009 01:31 PM
 
        To:     "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Michael A. 
Puls II" <shadow@shadow2531.com>
        cc:     "jwz@jwz.org" <jwz@jwz.org>, "PUBLIC-IRI@W3.ORG" 
<PUBLIC-IRI@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: '#' in mailto URIs


What about encouraging URI/IRI scheme registrations to
say about whether fragment identifiers are necessary,
important, useful, allowed.

mailto: could then disallow # fragment identifiers.

Larry

-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] 
Sent: Tuesday, October 13, 2009 9:37 PM
To: Michael A. Puls II
Cc: Larry Masinter; jwz@jwz.org
Subject: Re: '#' in mailto URIs

This is some very old mail. The current mailto: draft doesn't contain 
anything about fragment identifiers. Should it?

The text that I might put in (if we think we need some) is:

 >>>>
Note that this specification, like any URI scheme specification, does 
not define syntax or meaning of a fragment identifier, because these 
depend on the media type of the retrieved resource. In the currently 
known usage scenarios, a 'mailto' URI does not serve to retreive a 
resource with a media type. Therefore, fragment identifiers are 
meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be ignored 
upon resolution.
 >>>>

Regards,   Martin.

On 2008/04/02 6:32, Michael A. Puls II wrote:
>
> <!--"charset=utf-8"-->
> On Tue, 01 Apr 2008 13:18:27 -0400, Larry Masinter <LMM@acm.org> wrote:
>
>>> So, it sounds like, in short, you're saying that Safari and Firefox
>>> shouldn't use # that way because it's reserved for future use in 
mailto
>>> URIs.
>>>
>>> Perhaps you could explicitly note that in your next draft?
>>
>> It isn't reserved "for future use", it's just not allowed.
>
> Martin said that # is *always* a fragment identifier. If it's not
> allowed, ever, then you're saying that mailto URIs don't support
> fragment identifiers and won't ever support fragment identifiers because
> # is not allowed. (Which would make sense to me)
>
> If that's true, then a raw # that is found in a mailto URI (even though
> it's not allowed) would not be anything special and could just be
> accepted literally (if you were not going to throw an error).
>
> That would make sense to me.
>
> However, if mailto URIs support fragment identifiers or might support
> fragment identiers in the future, then # and everything after it in the
> URI needs to be ignored (at least by the mail client itself when parsing
> and filling in the compose fields).
>
> What I got from Martin's response is that mailto URIs (like http URIs)
> support fragment identifiers. It's just that no client *currently* makes
> use of them in any way for 'mailto'.
>
> Basically, I just need to be sure what to do with a raw # in a mailto
> URI (even if it's an error).
>
>> Not every possible string has to have an interpretation.
>
> I don't know what you mean by that sentence or what it pertains to.
> Please clarify.
>
> Thanks
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Wednesday, 14 October 2009 21:55:15 UTC