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

Larry Masinter <> Tue, 08 May 2012 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9279A21F84FF for <>; Tue, 8 May 2012 05:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.371
X-Spam-Status: No, score=-105.371 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qoysEm+7kO8i for <>; Tue, 8 May 2012 05:03:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7632521F84D1 for <>; Tue, 8 May 2012 05:02:42 -0700 (PDT)
Received: from ([]) by ([]) with SMTP ID; Tue, 08 May 2012 05:03:07 PDT
Received: from (inner-relay-4b []) by (8.12.10/8.12.10) with ESMTP id q48C2TIf026411; Tue, 8 May 2012 05:02:29 -0700 (PDT)
Received: from ( []) by (8.12.10/8.12.9) with ESMTP id q48C02Z1002873; Tue, 8 May 2012 05:02:27 -0700 (PDT)
Received: from ([]) by ([]) with mapi; Tue, 8 May 2012 05:01:52 -0700
From: Larry Masinter <>
To: "" <>, "" <>
Date: Tue, 8 May 2012 05:05:00 -0700
Thread-Topic: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu
Thread-Index: Ac0tElqZGy3KrakqSs2GqjvSXuCv/w==
Message-ID: <51dc9962-71b7-4821-8280-95c84c466dc9@blur>
References: <81fc13c0-e1eb-4b05-a81f-31aa2ef3ac65@blur>
In-Reply-To: <81fc13c0-e1eb-4b05-a81f-31aa2ef3ac65@blur>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_51dc996271b74821828095c84c466dc9blur_"
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, Mark Nottingham <>, "" <>
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: Tue, 08 May 2012 12:03:09 -0000

side note that w3c media fragments working group has proposed rec covering using fragments for temporal media, which i think is relevant ...mmusic should review asap.

Connected by DROID on Verizon Wireless

-----Original message-----
From: Magnus Westerlund <>
To: "" <>
Cc: Larry Masinter <>om>, Ted Hardie <>om>, "" <>rg>, "" <>
Sent: Tue, May 8, 2012 11:48:16 GMT+00:00
Subject: Re: [Uri-review] In WG last call review of URI Schemes rtsp, rtsps and rtspu

On 2012-05-08 12:15, Julian Reschke wrote:
> On 2012-05-08 11:45, Magnus Westerlund wrote:
>> Larry,
>> Can you please clarify something for me. What I have done is that I have
>> made it clear in the URI syntax that the fragment ABNF construct from
>> RFC 3986 MAY occur in an valid rtsp URI syntax. Are you saying that this
>> is not the right thing to do? How could I then indicate the appropriate
> It's pointless, as a URI scheme definition can't override RFC 3986, and
> parsing of scheme name and fragment are already defined by RFC 3986.
> Optimally, a new scheme definition just defines the scheme-specific part.
>> syntax  when the fragment identifier occur with the URI scheme being
>> defined? Can't I even say that fragments is not allowed for a scheme?
> No.
>> This appear to be the case if one would implicitly define the fragment
>> in an URI scheme.
> Exactly :-)

But, then what I have done isn't wrong either as I haven't override the
rules for fragment, only made it clear how they interface with the URI
definition. From my perspective I can remove the fragment syntax
definition, but I would instead at least explicitly call out that
fragments may occur following RFC 3986 syntax. Personally I don't see
that as being better.

Secondly, when we are on this topic. Can someone answer how you
determine the media type for an rtsp URI? RTSP URI points to resources
that can provide controlled playback of the resource using any number of
media types in form of RTP payloads formats depending on what is
suitable for the resource. In fact from issuing an PLAY request on an
audio only resource you still can receive a media stream where the
format it is encoded my actually change during the playback operation.

To be clear I don't plan to define a fragment handling format for RTSP
URIs, but there has been discussion in the past the desire has been to
do something that is media format agnostic. The goal has been to have an
uri where you basically say: Play this resource from 5 min 10 seconds
until 9 min 37 seconds. The proposal is in this 2005 draft.

But, if the above really isn't possible the question of fragments for
RTSP is really mote and is just a waste of time to discuss.


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: