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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

HAAS Christian skrev:
> Hello again;
> 
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com] 
>> [...]
>> 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
> 
> 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.
> 

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.

> 
>>> 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. [...]
> 
> 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).

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

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

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.

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

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.

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

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

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic