#225 Usage of Content-Location
From Tom Taylor during second WG last call:
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.
Martin's response:
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.
Discussion
