Subject: [MMUSIC] Request URI with query and control URI

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Oct 2008 10:13:40 +0100

Hi,

Christian logged the following ticket at source forge:
https://sourceforge.net/tracker2/?func=detail&aid=2038449&group_id=23194&atid=377747
> 
> Current client implementations append the (relative) control URI at the end of the request URI. If the request URI contains a query, the results are difficult to parse;
> 
> Example:
> Request URI:
> rtsp://server:554/greetings/?person=Bob
> Controls (in SDP) for audio and video streams:
> a=control:voice_audio
> a=control:front_image
> 
> Current result:
> rtsp://server:554/greetings/?person=Bob/voice_audio
> -> problems parsing URI (person := "Bob/voice_audio")

This is not following the relative reference rules specified in RFC
3986. What I understand the correct processing result would be:

rtsp://server:554/greetings/voice_audio

The query is not maintained from the Base URL if there is a path
component present in the relative one.

So in fact maintaining the URI query component requires one to copy it
into the relative reference, i.e.

rtsp://server:554/greetings/?person=Bob
Controls (in SDP) for audio and video streams:
a=control:voice_audio?person=Bob
a=control:front_image?person=Bob

Which when processed would result in:

rtsp://server:554/greetings/voice_audio?person=Bob

> 
> Possible alternative:
> rtsp://server:554/greetings/voice_audio/?person=Bob
> -> might have even more problems (/greetings/voice_audio/ results in 404
> or query not understood)
> 
> Proposal:
> rtsp://server:554/greetings/?person=Bob#voice_audio
> 
> Fragments are currently not defined (allowed) for messaging between client and server and one stream of several within a presentation could be seen as 'fragment' of the presentation.
> 

Yes, because they are client local instructions. For RTSP the most
logical fragment extension is format that specifies where to start to
play. So if you embedded a URI with a fragment of this type in a webpage
the RTSP client that deals with the URI would use the fragment to to
construct a range header to request the start time.

> If fragments are not going to be the solution, please provide examples
> and/or definitions on how to apply and parse the control URI.

No, I don't want to mess with the standard URI parsing rules. Although
they are problematic in this case.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "HAAS Christian" <[email-masked]>
Date: Fri, 31 Oct 2008 08:34:15 +0100

Hello again;

From: Magnus Westerlund [mailto:[email-masked]] 
> [...]

I don't know how complex the virtual paths for resources can become on a
server, but with this method I believe it is going to be difficult to find
out what is what (base URI together with the query and the control name) -
although I could think of servers first working with the session id, which
then already has associated what the original parameters were. Stripping them
away should leave the control name.

> > Fragments are currently not defined (allowed) for messaging
> > between client and server and one stream of several within
> > a presentation could be seen as 'fragment' of the presentation.
>
> Yes, because they are client local instructions. [...]

Which is why I proposed to use them - since they were handled (and thus
filtered) by the client, they would have been available for the signalization
between client and server; But I just got remembered about a case where a
RTSP URI (with query) links to a specific section only of the audio stream
for example (which would look like this:
rtsp://server:554/meetings/audio_track?id=1234#introduction).

In sum, the 'best' solution would be to have the query put into the control
URI as well, as you described. Although, since these relative strings are
only appended to the original URI by some clients (as seen with Real Player
and Quicktime), the server might end up receiving something like
rtsp://server:554/greetings/?person=Bob/voice_audio?person=Bob
To cover all bases, I guess the best a server could do with queried URIs is
to put the absolute string for the control property.

>From my point of view, the tracker item can be closed.

Regarding the fragments (derailing the original topic a little): How are
these fragments defined/interpreted for and by the client anyway? In my
example above, how would the client know fragment 'introduction' refers to
npt=10.0-120.0 ?
The spec only states
> The user agent also needs to interpret the value of the fragment
> based on the media type the request relates to; i.e., the media
> type indicated in Content-Type header in the response to DESCRIBE
This might be a dedicated topic (for SDP?)...

Regards,
ch
____________________________________________________
Christian Haas
Team DIVOS, Software Engineer
FREQUENTIS AG

Innovationsstraße 1, 1100 Vienna, Austria
Phone   +43-1-811 50 - 8353
Mobile   +43-664-60 850 - 8353
Fax       +43-1-811 50 - 77 8353
Web      www.frequentis.com
E-Mail    [email-masked]
 
Handelsgericht Wien (Vienna Commercial Court): FN 72115 b
DVR 0364797, ATU 14715600
____________________________________________________
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Oct 2008 10:56:38 +0100

> away should leave the control name.

I am simply pointing out that the rules we are using defined in RFC 3986
do result in this behavior. I personally don't think changing these
processing rules are beneficial. The rules for RFC 2326 are very
uncertain as this whole things is underspecified.

So the question around this to the community is if we really see enough
benefit in breaking compatibility with the generic URI rules?

My vote is definitely for no.

> rtsp://server:554/meetings/audio_track?id=1234#introduction).

Yes, if the clients know how to interpret "introduction" that is after
all depending on the media type.

> to put the absolute string for the control property.

I think using absolute URI are the simplest solution today. If you
anyway are rewriting the SDP. Currently there are no way to avoid
rewriting the SDP if one uses query.

> example above, how would the client know fragment 'introduction' refers to

Currently there is no definition. There has been a draft that proposed a
fragment for this since long expired:

http://tools.ietf.org/html/draft-pfeiffer-temporal-fragments-03

If one is going to use this it needs standardization. If one are going
to go so far to allow symbolic name there needs to be a resolution
mechanism.

> This might be a dedicated topic (for SDP?)...

Yes, it needs work. And it gets even more hairy in that the fragment as
to be interpreted in the context of the media the URI identifies. And I
can clearly see how one can interpret the media type for a streaming
resource to not be SDP but something else. I think one can generalize
this for RTSP as proposed in the above draft.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 31 Oct 2008 11:25:56 +0100

> My vote is definitely for no.

My empirical experience is that various RTSP (1.0) clients implement this
in various ways, from plain dumb concatenation to proper RFC3986
implementation. If it were me, I would mandate absolute URIs in a=control.
This would additionally allow "exporting" any SDP from RTSP DESCRIBE
without changes.

I am not very optimistic about implementors fixing their crappy
implementations. RTSP is already so complex that it's essentially
impossible to not violate the spec (either by accident or to avoid bloat).
In other words, whatever the spec says, the only way a server will
interoperate is by sticking to absolute URIs.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Oct 2008 13:29:26 +0100

> This would additionally allow "exporting" any SDP from RTSP DESCRIBE

Considering how unclear the whole URI processing are in RFC 2326 I am
not surprised that is how they do it.

> interoperate is by sticking to absolute URIs.

Okay, I am more optimistic and think the correct response, is to
actually make the warning in RFC 3986 about old non compliant more
evident in the place where it do matter and there recommend usage of
absolute URIs.

Cheers

Magnus Westerlund

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 15:00:07 +0200

On Friday 31 October 2008 14:29:26 ext Magnus Westerlund, you wrote:
> > impossible to not violate the spec (either by accident or to avoid
> > bloat). In other words, whatever the spec says, the only way a server
> > will interoperate is by sticking to absolute URIs.
>

Right, this would make sense. One sentence in the list of differences from 
RFC2326, especially.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Oct 2008 14:20:42 +0100

> Right, this would make sense. One sentence in the list of differences from 

I have added a note in the a=control section:

Note, RFC 2326 was very unclear on the processing of relative URI and
several RTSP 1.0 implementations at the point of publishing this
document did not perform RFC 3986 processing to determine the resulting
URI, instead simple concatenation is common. To avoid this issue
completely it is recommended to use absolute URI in the SDP.

The changes section needs a total make over. We need to reduce the
details while still capturing all the important changes. That is still
for the future and requires quite some work. But, I agree being clear on
that URI been clarified including relative processing rules are appropriate.

Cheers

Magnus Westerlund