Subject: Re: [MMUSIC] ETag Definition in draft-rfc2326bis-06

From: Pekka Pessi <[email-masked]>
Date: Thu, 01 Apr 2004 21:09:38 +0300

Magnus Westerlund <[email-masked]> writes:
>Thanks for spotting this. I need some help with this as I have not a
>complete understanding of how ETag is supposed to work. I understand that
>they are server defined entities that only needs to follow the syntax.

>So what I understand there is need for a RTSP header "ETag:<tag>" that can
>be included in DESCRIBE and SETUP messages to be used to determine what
>content the client actually wants to SETUP or question if the description is
>up-to-date.

I *think* that the idea is when you get an SDP from HTTP server or
in response to DESCRIBE, you also get an a=etag. You then include
the tag in the If-Match header of the SETUP request. If the tag is
valid, the SETUP continues as usual. If the media resource has
changed (or the tag is not valid for any other reason) the server
should return 412. 

Now that ANNOUNCE/RECORD have been removed, I don't think we have
any use of If-Match with DESCRIBE.

According to RFC 2326, 304 is returned when a DESCRIBE or
SETUP has an If-Modified-Since header. The Last-Modified/
If-Modified-Since mechanism is borrowed from HTTP/1.0. The
description of 304 with ETag in bis-06, however, is pasted from
HTTP/1.1.

So, when you get a 304 response with ETag in HTTP/1.1? Lets
suppose you have done GET and got 200 with the resource contents
and ETag: "xyzzy". Later you send GET with If-None-Match: "xyzzy",
if the server has not changed the resource it could respond with
304 and the ETag "xyzzy".

When using the HTTP/1.1 entity tags there can multiple versions
of the same resource, say, Swedish and Finnish web pages. The
server could select a particular version based on the request (in
this case, Accept-Language header in it). It would include a ETag
and Content-Location headers in the response (probably also the
Content-Language). A client (or proxy) could cache all the
different versions. It can ask server if one of them is valid for
a particular request by including all the cached ETags in the
If-None-Match header of the GET request. The 304 response would
then contain the ETag and Content-Location for the correct web
page.

So, I think options for bis-07 are:

1) deprecate If-Modified-Since and introduce If-None-Match
2) ditch ETag header in 304 and continue to use the current mix of
   HTTP/1.0 and HTTP/1.1 mechanisms

>Having a ETag header in the describe response seem to have some
>possibilities to clash with the SDP usage. In session
>descriptions it seems much better to have the ETag in the
>description so one does not have to add it if one for example
>saves the SDP.

Yes. However, I could imagine a "particular session description
language" that does not have etag, so the ETag header would be
needed.

--Pekka

>Jae-Hwan Kim wrote:
>> Dear MMUSICers,
>> Please look at the page 60 mentioning ETag header field. Basically, "304
>> Not modified" response is always supposed to have this
>> header field.
>> However, where is ETag definition in this spec.?
>> In addition, when ETag is used in DESCRIBE response, should a client
>> ignore this field?
>> I found a commercial RTSP server had this field in the DESCRIBE
>> response.
>> TIA/BR, Jae-Hwan
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 06 Apr 2004 09:12:37 +0200

Thanks Pekka,

See some comments below.

> any use of If-Match with DESCRIBE.

I agree that the usage of If-Match may not any longer be useful with 
DESCRIBE. However it is still useful for SETUP, where one can utilize in 
for example redirection to verify that one does SETUP on a resource 
where one has a valid session description.

>    HTTP/1.0 and HTTP/1.1 mechanisms

I don't think there are reasons to deprecated If-Modified-Since. It is 
still useful for cases when one likes to use HTTP dates. However adding 
If-None-Match to enabled conditional retrieves with DESCRIBE seems 
beneficial.

> language" that does not have etag, so the ETag header would be

Agree, then the proposal is to include also the ETag header in RTSP. 
Comments on this.

Summary of proposed changes:

- Add ETag header.
- Add If-None-Match
- Clarify If-Match
- Clarify usage of ETags in general and their usage.

Comments?

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Pekka Pessi <[email-masked]>
Date: Thu, 08 Apr 2004 15:43:54 +0300

Hello Magnus,

>I don't think there are reasons to deprecated If-Modified-Since. 
>It is still useful for cases when one likes to use HTTP dates. 
>However adding If-None-Match to enabled conditional retrieves
>with DESCRIBE seems beneficial.

Yes, you are right. By "deprecating" I meant that no-one should
build a new RTSP client that uses If-Modified-Since only.

>Comments?

Also, a clarification of Accept-Language/Content-Language could be
in order. Accept-Language now states that 

   the language specified applies to the presentation description
   and any reason phrases, not the media content.

However, ETag effectively allows clients and proxies to cache
alternative contents for a particular resource. If we have two SDP
descriptions for URI in different languages, I'd expect that they
can refer to two different media resources. The actual media could
be in different languages, too, but the language must be chosen
before the SETUP is sent. For example, we can ask for Finnish SDP:

C->S: DESCRIBE rtsp://localhost/news RTSP/1.0
      Accept-Language: fi
      CSeq: 1

S->C: RTSP/1.0 200 OK
      CSeq: 1
      Content-Location: /news.fi/sdp
      Content-Language: fi
      Content-Type: application/sdp
      Last-Modified: Wed, 07 Apr 2004 23:15:22 GMT
      Date: Thu, 08 Apr 2004 14:44:22 GMT
      ETag: "1d387f94c4bf2b8aad21271c27cd456e"
      Content-Length: ...

      v=0
      o=news 32178463 8147637 IN IP6 ::1
      s=Nyytiset
      t=0 0
      a=range:npt=0-13:34
      m=audio 8468 RTP/AVP 96
      a=control:audio
      a=rtpmap:96 AMR-WB/16000

and swedish SDP:

C->S: DESCRIBE rtsp://localhost/news RTSP/1.0
      Accept-Language: se
      CSeq: 2

S->C: RTSP/1.0 200 OK
      CSeq: 2
      Content-Location: /news.se/sdp
      Content-Language: se
      Content-Type: application/sdp
      Last-Modified: Thu, 08 Apr 2004 14:44:22 GMT
      ETag: "140940f8c9aa3e2a9df426cd1d626f7a"
      Content-Length: ...

      v=0
      o=news 32178463 8147637 IN IP6 ::1
      s=Uuheter
      t=0 0
      a=range:npt=0-13:34
      m=audio 8468 RTP/AVP 96
      a=control:audio
      a=rtpmap:96 AMR-WB/16000

and then we can use the SDP (and Content-Location URL) to the
select the language:

C->S: SETUP rtsp//localhost/news.se/audio RTSP/1.0
      CSeq: 3
      Transport: RTP/AVP;unicast;client_port=5004-5005

S->C: RTSP/1.0 200 OK
      CSeq: 2
      Session: 9bc0d7421edc303a93ae2dacc7117150
      Transport: RTP/AVP;unicast;client_port=5004-5005;server_port=3056-3057

--Pekka