Subject: [MMUSIC] Content-Location in RTSP 2.0

From: Tom Taylor <[email-masked]>
Date: Tue, 29 Jun 2010 09:54:39 -0400

While you're doing such a beautiful job of cleaning up RTSP 2.0 issues, I have 
another for consideration. I'm having trouble understanding the meaning of 
Content-Location in RTSP.

The basic problem is that Content-Location comes from HTTP, where the entity and 
the resource are in a certain sense the same thing. It makes sense in HTTP to 
provide a pointer to the original location of the entity, since one can refer to 
it in a later operation.

It makes no sense to point to the original location of an RTSP entity (i.e., the 
presentation description, the SDP) because there is no way one can use that 
pointer (URI) in a subsequent request.

An alternative interpretation of the Content-Location header is that it points 
to the resource instance that is the subject of the message concerned. However, 
that is the role of the Location header if I understand it correctly.

My conclusion, subject to correction of any misunderstandings, is that the 
Content-Location header has no point in RTSP and should be dropped.

Tom Taylor

---

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 30 Jun 2010 10:01:56 +0200

Hi Tom,

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, June 29, 2010 3:55 PM
> To: mmusic; Martin Stiemerling
> Subject: Content-Location in RTSP 2.0
> 

Not sure, if I'm doing a beautiful job wrt RTSP 2.0 ;)

> that is the role of the Location header if I understand it correctly.

One usage not described above is for cache handling of SDPs (Section 18.2) and related checking if a resource has been modified (Section 15.3.4). 

The checking if a resource has been modified (Section 15.3.4) can be done without the Content-Location header by using MTags. 

However, the cache handling in Section 18.2 might require this, as the Content-Location header can be used to determine whether the SDP requested is still up-to-date or not. However, the caching part may be under specified, as it inherits a lot from HTTP, but not all parts. 

I also have to admit that the Content-Location header might be indeed to much legacy inherited of HTTP. 

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Tom Taylor <[email-masked]>
Date: Wed, 30 Jun 2010 08:23:16 -0400

I can see the possibility of using Content-Location to check on the currency of 
an SDP cache. That doesn't require retrieving content through the URI, just 
making comparisons with it.

We should probably make MTags the only way to check on currency of cached resources.

> Hi Tom,
...

>> 
>> It makes no sense to point to the original location of an RTSP entity 
>> (i.e., the presentation description, the SDP) because there is no way one
>> can use that pointer (URI) in a subsequent request.
>> 
...

> 
> One usage not described above is for cache handling of SDPs (Section 18.2)
> and related checking if a resource has been modified (Section 15.3.4).
> 
> The checking if a resource has been modified (Section 15.3.4) can be done
> without the Content-Location header by using MTags.
> 
> However, the cache handling in Section 18.2 might require this, as the
> Content-Location header can be used to determine whether the SDP requested is
> still up-to-date or not. However, the caching part may be under specified, as
> it inherits a lot from HTTP, but not all parts.
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited |
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in
> England 2832014 _______________________________________________ mmusic
> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> 
>