Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

["Martin J. Dürst" <[e-mail]>]

On 2012/05/09 3:36, Roy T. Fielding wrote:
> On May 8, 2012, at 10:55 AM, Ted Hardie wrote:
>> Well, perhaps a less theoretical distinction would be whether or not
>> what a URI is associated can have a media type.  A media type for
>> mailto:[e-mail] is
>> not really sensible; a fragment for that identifier is thus not sensible.
>
> No, fragments have nothing to do with the definition of schemes.
> They occasionally have something to do with how schemes are used,
> such as
>
>     mailto:[e-mail]#subject
>
> could be used, for example, to refer to either the owner of that mailbox
> or to opening an email entry form with "[e-mail]" pre-filled
> in the To field and the active cursor placed in an input field named
> subject.  We don't know its true definition, if any, until someone
> builds a system that happens to use the identifier in that fashion.

This is what both http://tools.ietf.org/html/rfc6068 ("The 'mailto' URI 
Scheme") and http://tools.ietf.org/html/draft-duerst-eai-mailto-03 (an 
update to include EAI) currently say on this topic:

    Note that this specification, like any URI scheme specification, does
    not define syntax or meaning of a fragment identifier (see [STD66]),
    because these depend on the type of a retrieved representation.  In
    the currently known usage scenarios, a 'mailto' URI cannot be used to
    retrieve such representations.  Therefore, fragment identifiers are
    meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
    ignored upon resolution.  The character "#" in <hfvalue>s MUST be
    escaped as %23.

This seems to be fully in line with the discussion up to here, including 
Roy's comment above, but if anybody thinks it needs to be changed, 
please send some new proposed wording.

Taking the above text, and adopting it for the rtsp situation, might 
lead to something like:

    Note that this specification, like any URI scheme specification, does
    not define syntax or meaning of a fragment identifier (see [STD66]),
    because these depend on the type of a retrieved representation.  For
    'rtsp', 'rtsps', and 'rtspu' URIs, care has to be taken that a
    fragment identifier designates equivalent subresources across the
    media types that can be returned when resolving the URI.


In terms of syntax, I think that as things stand, Magnus has a point.
Scheme definition specs that use rules in the way this is done in 
http://tools.ietf.org/html/rfc6068#section-2, i.e. without adding an 
optional fragment part, are technically wrong. On the other hand, specs 
such as the XMPP URI/IRI spec, which includes #(i)fragment (see 
http://tools.ietf.org/html/rfc5122#page-6), are technically correct.

The fact that e.g. the mailto: spec gets this wrong seems to be a 
leftover of the change from RFC 2396, where fragments were not 
considered to be part of an URI, but together with an URI formed what 
was called an URI reference (see 
http://tools.ietf.org/html/rfc2396#appendix-A), and RFC 3986 
(http://tools.ietf.org/html/rfc3986#appendix-A), where URIs 
syntactically included fragment identifiers. This was the right change 
for a lot of reasons, but as we are finding out now somehow seems to 
leave URI scheme designers in a tough place because syntactically, they 
should mention the fragment, but semantically, they better wouldn't.

I think we need to look at some more URI/IRI registrations from this 
point of view to see what's best for RFC 4395bis.

Regards,   Martin.