Subject: [MMUSIC] RTSP 2.0: Vary header -- where to go with this

From: Martin Stiemerling <[email-masked]>
Date: Tue, 21 Feb 2012 10:46:21 +0000

Dear all,

draft-ietf-mmusic-rfc2326bis-28 specifies the Vary header in Section 16.55. I have included the full text if this section below, for your reference. 

This header has been taken from HTTP/1.1 and did appear in past versions of draft-ietf-mmusic-rfc2326bis-28 as a simple reference to HTTP, i.e., without any explanation of what this header really means in RTSP. We copied and adapted the current text from HTTP/1.1 in one of the revisions of RTSP 2.0. 

However, we got the comment that Vary as operation is very unclear and it is unclear if any existing RTSP 1.0 implementation is actually using this. It might be a good first indicator that Vary is not needed in RTSP 2.0 at all, if there is no implementation using this in RTSP 1.0. 

I can see why this header is available in HTTP, but I have doubts about in RTSP. 

Let me know your opinion.

Here is the full text of Section 16.55

   The Vary field value indicates the set of request-header fields that
   fully determines, while the response is fresh, whether a cache is
   permitted to use the response to reply to a subsequent request
   without revalidation.  For uncacheable or stale responses, the Vary
   field value advises the user agent about the criteria that were used
   to select the representation.  A Vary field value of "*" implies that
   a cache cannot determine from the request headers of a subsequent
   request whether this response is the appropriate representation.

   An RTSP server SHOULD include a Vary header field with any cacheable
   response that is subject to server-driven negotiation.  Doing so
   allows a cache to properly interpret future requests on that resource
   and informs the user agent about the presence of negotiation on that
   resource.  A server MAY include a Vary header field with a non-
   cacheable response that is subject to server-driven negotiation,
   since this might provide the user agent with useful information about
   the dimensions over which the response varies at the time of the
   response.

   A Vary field value consisting of a list of field-names signals that
   the representation selected for the response is based on a selection
   algorithm which considers ONLY the listed request-header field values
   in selecting the most appropriate representation.  A cache MAY assume
   that the same selection will be made for future requests with the
   same values for the listed field names, for the duration of time for
   which the response is fresh.

   The field-names given are not limited to the set of standard request-
   header fields defined by this specification.  Field names are case-
   insensitive.

   A Vary field value of "*" signals that unspecified parameters not
   limited to the request-headers (e.g., the network address of the
   client), play a role in the selection of the response representation.
   The "*" value MUST NOT be generated by a proxy server; it may only be
   generated by an origin server.

  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: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Feb 2012 09:42:38 +0100

WG,

My personal opinion of this is that we should remove Vary. This is a
piece of HTTP that seems to poorly match RTSP and would need significant
work to be made functional.

For example Vary talks about server-driven negotation which isn't
explained in the RTSP 2.0 spec at all. If you want to know of it you
need to go read section 12.1 of RFC 2616 (HTTP).

Although the idea behind the vary header may be usful for RTSP media
stream caching I suspect a different approach is needed. If there is
interest in any issue that would arise due to the cache and server not
knowing the criterias for tailoring of  the delivered media stream
present in the cache then a more suitable solution will need to be
developed.

Cheers

Magnus

On 2012-02-21 11:46, Martin Stiemerling wrote:
> Dear all,
> 
> draft-ietf-mmusic-rfc2326bis-28 specifies the Vary header in Section
16.55. I have included the full text if this section below, for your
reference.
> 
> This header has been taken from HTTP/1.1 and did appear in past
versions of draft-ietf-mmusic-rfc2326bis-28 as a simple reference to
HTTP, i.e., without any explanation of what this header really means in
RTSP. We copied and adapted the current text from HTTP/1.1 in one of the
revisions of RTSP 2.0.
> 
> However, we got the comment that Vary as operation is very unclear
> and
it is unclear if any existing RTSP 1.0 implementation is actually using
this. It might be a good first indicator that Vary is not needed in RTSP
2.0 at all, if there is no implementation using this in RTSP 1.0.
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 29 Feb 2012 15:33:50 +0000

Hi all, 

I basically see it the same way, Vary is useful in HTTP but it will require a lot work to bring to RTSP without seeing a clear need for it. 

I will remove the Vary header from the upcoming version of the draft, unless somebody has any objection to it. 

  Martin

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, February 28, 2012 9:43 AM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: Re: [MMUSIC] RTSP 2.0: Vary header -- where to go with this
> 
> WG,
> 
> > NEC Laboratories Europe - Network Research Division NEC Europe Limited |
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in
> England 2832014
> >
> >