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

Julian Reschke <> Tue, 08 May 2012 12:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EABC421F8470 for <>; Tue, 8 May 2012 05:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.123
X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ITOqV-TdPxkl for <>; Tue, 8 May 2012 05:14:49 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D1CCA21F846E for <>; Tue, 8 May 2012 05:14:48 -0700 (PDT)
Received: (qmail invoked by alias); 08 May 2012 12:14:47 -0000
Received: from (EHLO []) [] by (mp070) with SMTP; 08 May 2012 14:14:47 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/WOJ4twpjWkHAfgQCgbNz3SW9pJ9ehgRAgbGvdjs JXkOzMFpomN4C7
Message-ID: <>
Date: Tue, 08 May 2012 14:14:32 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: 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: Tue, 08 May 2012 12:14:50 -0000

On 2012-05-08 13:48, Magnus Westerlund wrote:
> 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.


I agree that what the spec does isn't wrong; it's just a bit misleading 
in that it implies that a URI scheme definition has *any* authority over 
the fragment identifier.

> 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.
> ...

As Larry just mentioned: <>

Best regards, Julian