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

"Roy T. Fielding" <> Wed, 09 May 2012 04:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C2C711E808A for <>; Tue, 8 May 2012 21:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.154
X-Spam-Status: No, score=-104.154 tagged_above=-999 required=5 tests=[AWL=-1.855, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A0GQmVzNyyNu for <>; Tue, 8 May 2012 21:28:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 80EAE11E8074 for <>; Tue, 8 May 2012 21:28:52 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id D80D194059; Tue, 8 May 2012 21:28:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns;; b=A2OyxIF9TDNAwZMH XcpRQsm0vJ+xMgXFms7Ycsz77TwqfilYeHcQRUk4rARyENO1gmBSSlAl/mWiSTl8 P+5YR31zoR/mUXIz+FcDJbhgkyw7pKFzbHMk+qqeSWk3qxD0BakOXtCzKvnl1cQ1 yquWDbhVMqTrByAAERdVPSK/OdM=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=lerkz7uHRAXOtjo4APj0HgaosdI=; b=APYaTGRrbYv/gwlYVEgiLAoxjzUR G6uTMFBON3EuNQ1GOg0m13dCu91a9rJuVvM6VnicN0hGJAnqjn/i7Y7aUxh/1ZcP jgMiPZ3xCoNBRci8wCjfO9bJuqjblsvUjGfYteKa2ycqbD4Hn3hH2zaHz/NgyrNZ oiW9tmDMEPlz3RI=
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id A204A94065; Tue, 8 May 2012 21:28:50 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Tue, 8 May 2012 21:28:56 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <>
X-Mailer: Apple Mail (2.1257)
Cc: Julian Reschke <>, "" <>, Ted Hardie <>, "" <>, "" <>
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 May 2012 04:28:53 -0000

On May 8, 2012, at 6:42 PM, Martin J. Dürst wrote:
> 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
>>> 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
>> could be used, for example, to refer to either the owner of that mailbox
>> or to opening an email entry form with "" 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 ("The 'mailto' URI Scheme") and (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.

The second to last sentence is wrong.  That spec cannot make
normative requirements about something that is out of scope;
any fragment is completely outside the scope of a URI scheme
specification.  Just remove the "Therefore, ... resolution."
sentence -- it serves no useful purpose.