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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 09 May 2012 01:42 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDA211E808C for <uri-review@ietfa.amsl.com>; Tue, 8 May 2012 18:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.224
X-Spam-Level:
X-Spam-Status: No, score=-99.224 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySR-5KZvXj5q for <uri-review@ietfa.amsl.com>; Tue, 8 May 2012 18:42:47 -0700 (PDT)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2807121F848B for <uri-review@ietf.org>; Tue, 8 May 2012 18:42:46 -0700 (PDT)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q491gfIu029830 for <uri-review@ietf.org>; Wed, 9 May 2012 10:42:41 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5f89_5185_43c8ab08_9978_11e1_a798_001d096c566a; Wed, 09 May 2012 10:42:40 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35516) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15C2752> for <uri-review@ietf.org> from <duerst@it.aoyama.ac.jp>; Wed, 9 May 2012 10:42:44 +0900
Message-ID: <4FA9CB84.8030609@it.aoyama.ac.jp>
Date: Wed, 09 May 2012 10:42:28 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@gbiv.com>
References: <4F99665D.8060404@ericsson.com> <CA+9kkMAvr6eXHzB_HMVgGqBHpUpeuh-mrWRP6-Ap0w3SZLvV-Q@mail.gmail.com> <4FA13522.6020103@ericsson.com> <C68CB012D9182D408CED7B884F441D4D194AD547DE@nambxv01a.corp.adobe.com> <4FA8EB2E.8070609@ericsson.com> <4FA8F231.90407@gmx.de> <CA+9kkMCOatpOO2P5c0PxSt=CKfUCG2pOaKYNkP-e-80ianps1Q@mail.gmail.com> <4FA95C23.3030802@gmx.de> <CA+9kkMBzae-tcMSjidwLF5kD5_FD1soNDGOgWA+jLLH0QYVLfA@mail.gmail.com> <F83F17D2-8E61-4F43-A183-8EC457291A59@gbiv.com>
In-Reply-To: <F83F17D2-8E61-4F43-A183-8EC457291A59@gbiv.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, "public-iri@w3.org" <public-iri@w3.org>, Ted Hardie <ted.ietf@gmail.com>, "uri-review@ietf.org" <uri-review@ietf.org>, "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 May 2012 01:42:48 -0000

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:ted.ietf@gmail.com 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:ted.ietf@gmail.com#subject
>
> could be used, for example, to refer to either the owner of that mailbox
> or to opening an email entry form with "ted.ietf@gmail.com" 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.