Subject: [MMUSIC] RTSP draft changes from telecon

From: Tom Marshall <[email-masked]>
Date: Wed, 8 Jan 2003 15:01:14 -0800

I volunteered to make some changes to draft-02 during the last telecon (see
http://www.rtsp.org/2002/telecon/minutes11Dec.html).  It's been a while and
my memory is a bit fuzzy, so please verify the following is correct
(especially Rob and Magnus):

1. Fill in section 11.3.5 (304 response).  Reference section 12.23 and 12.9.

2. Modify 10.10 (REDIRECT) to clarify the following behavior:

  If a REDIRECT contains a Session: header, it is end-to-end and applies
  to the given session only.

  If a REDIRECT does not contain a Session: header, it is single-hop (eg. 
  handled by the proxy, if applicable) and applies to the control (tcp)
  connection.

-- 
I mean, if 10 years from now, when you are doing something quick and dirty,
you suddenly visualize that I am looking over your shoulders and say to
yourself, "Dijkstra would not have liked this", well that would be enough
immortality for me.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 09 Jan 2003 09:34:50 +0100

Hi Tom,

Seems correct to my memory.

>  handled by the proxy, if applicable) and applies to the control (tcp)
The last sentence about a REDIRECT's applicability to the control 
connection I can't remember discussing. However I do agree with you that 
it is a logical step to move the control connection. If a server is 
totally shutting down it will anyway need to close the TCP connections, 
so having at least SHOULD requirement on closing the connection seems 
fine by me.

Cheers

Magnus Westerlund 

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

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

---

From: Tom Marshall <[email-masked]>
Date: Thu, 9 Jan 2003 12:26:38 -0800

> >1. Fill in section 11.3.5 (304 response).  Reference section 12.23 and

I started writing this section and came across some issues:

1. When 304 is sent in response to a DESCRIBE, what exactly is meant by "not
modified"?  Does this response guarantee that the resource is not modified,
or merely that the description of the resource is not modified?  Here are
two examples: (1) a newer copy of a resource has been placed on the server,
but the resource description for the updated copy is identical, and (2) a
live resource.  In both cases, the resource description may be identical to
the previously returned copy, but the resource contents will not.  Is 304
appropriate?

2. Same issue with SETUP, but in reverse.  Does 304 necessarily imply that
the resource description is identical?

3. The RTSP state machine mandates that a 3xx response to a request changes
the state to Init.  This is fairly logical for the other 3xx codes, as they
are used for redirection.  Should 304 also follow this rule?  Suppose that a
client has a Session and is PLAYing a resource.  The client then issues a
DESCRIBE on that same resource, specifying the existing Session and an
If-Modified-Since header.  The server returns a 304 response.  What happens
to the Session?  Should it be considered torn down?  Should the server stop
sending data packets?

Further, suppose that the same scenario as (3) above plays out but the
server returns 302 instead.  What happens to the session, and should the
server stop sending data packets?

> so having at least SHOULD requirement on closing the connection seems 

I thought we had agreed on these semantics toward the end of the telecon. 
It seems that, in any case, we are in agreement.  If there are any
objections to the above semantics, please make them known asap.

-- 
I used to think I was a child; now I think I am an adult -- not because
I no longer do childish things, but because those I call adults are no
more mature than I am.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Jan 2003 09:24:22 +0100

Hi Tom,

Some comments

Tom Marshall wrote:

>>>1. Fill in section 11.3.5 (304 response).  Reference section 12.23
>>>      
>>>
>and
>  
>
>>>12.9.
>>>      
>>>
>

In my opinion the 304 answer to a DESCRIBE request must be related to if 
the session description is changed. The session content that the session 
description relates to is not part of the question. If the media content 
changes it should be published as a new resources with an new URI.

>the resource description is identical?

What is your suggestion for the semantics of receiving a 304 to a SETUP 
request? I have earlier asked what happens when one do SETUP to change 
parameters and it does not work correctly, see bug 513737:
https://sourceforge.net/tracker/?group_id=23194&atid=377744&func=detail&aid=513737

>to the Session?  Should it be considered torn down?  Should the server
I think 304 needs to be excluded from this behavior. Is it not in fact 
that a 304 response is the result of that the session state has not been 
changed?

>server stop sending data packets?
The scenario you think of is a DESCRIBE request with session header 
relating to a active session. That DESCRIBE request results in a 302 
response. However as DESCRIBE does not effect the session state (see 
table 6).
Also currently session header is not applicable for DESCRIBE requests 
(See table 4).

>>>If a REDIRECT contains a Session: header, it is end-to-end and
>>>      
>>>
>applies
>  
>
>>>handled by the proxy, if applicable) and applies to the control
>>>      
>>>
>(tcp)
>  
>
>>>connection.
>>>
>>>      
>>>
>>connection I can't remember discussing. However I do agree with you
>>    
>>
>that 
>  
>
>>totally shutting down it will anyway need to close the TCP
>>    
>>
>connections, 
>  
>
Yes, I think you are correct, just had some problem remembering that.

Cheers

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Mon, 13 Jan 2003 10:53:30 -0800

> >1. When 304 is sent in response to a DESCRIBE, what exactly is meant by
> >"not modified"?
> 
> description relates to is not part of the question.

Okay, that sounds logical to me.

> If the media content changes it should be published as a new resources
> with an new URI.

I agree that it is desirable to have a new URI for a changed resource, but I
don't think it should not be a MUST.  I don't think the spec should dictate
content policy to this degree.

> >2. Same issue with SETUP, but in reverse.  Does 304 necessarily imply
> >that the resource description is identical?
> 

The answer to my question is implied: a 304 response to a SETUP does not
guarantee that the resource description is unchanged.  Correct?

I admit that I have not thought about the issue in 513737 before.  It seems
to come from overloading the semantics of SETUP.

> that a 304 response is the result of that the session state has not been 

Yes, it would be logical to exclude 304 from the state change in this case. 
But wouldn't this break compatibility with 2326?  Are there existing RTSP
implementations that would reset the state to Init in this case?

> response. However as DESCRIBE does not effect the session state (see 

I think there is a conflict in the state change rules.  Perhaps the rules
for state changes need to be re-examined, or at least clarified?

> Also currently session header is not applicable for DESCRIBE requests 

This is true for draft-02, but 2326 section 12 says:

Header               type   support   methods
...
Session              Rr     req.      all but SETUP, OPTIONS

This is not strictly correct, as the Session header is indeed meaningful in
SETUP, but it does allow Session to be used in DESCRIBE.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 15 Jan 2003 12:06:05 +0100

Hi Tom,

>content policy to this degree.

No, I agree but we should be clear with what a certain answer means so. 
That way we can avoid ambiguities if different content policies are used.

>>What is your suggestion for the semantics of receiving a 304 to a
>>    
>>
>SETUP 
>  
>

I don't know actually. Lets start deciding what resource that a 
If-Modified-Since header actually relates to in a SETUP request. 
Comparing this with Last-Modified header which for a SETUP relates to 
the media stream. In that case it seems valid that the If-Modified-Since 
header in a request relates to the media stream also. In that case a 304 
would mean that the media stream which the URL in the request points at 
has not be changed.

Assuming that the media stream has not changed, how could a resource 
description in that case be different while the media is not different. 
If that is possible we should point out this fact and explicitly declare 
that a 304 answer does not in fact guarantee the resource description is 
still the same.

>to come from overloading the semantics of SETUP.
I don't think this problem of overloading is that problematic. I simply 
think that we need to clarify the behavior of reSETUP request that fails.

>>>the state to Init.  This is fairly logical for the other 3xx codes,
>>>      
>>>
>as
>  
>
>>>they
>>>client has a Session and is PLAYing a resource.  The client then
>>>      
>>>
>issues
>  
>
>>>a
>>>DESCRIBE on that same resource, specifying the existing Session and
>>>      
>>>
>an
>  
>
>>>to the Session?  Should it be considered torn down?  Should the
>>>      
>>>
>server
>  
>
>>>stop
>>>sending data packets?
>>>
>>>
>>>      
>>>
>>that a 304 response is the result of that the session state has not
>>    
>>
>been 
>  
>
>>changed?
>>    
>>
>
Looking at the RFC2326 state machine nothing of this is explicitly 
declared. Therefore I don't think there is a problem of fixing this in 
the new state machine.

>  
>
>>>Further, suppose that the same scenario as (3) above plays out but
>>>      
>>>
>the
>  
>
>>>server returns 302 instead.  What happens to the session, and should
>>>      
>>>
>the
>  
>

Yes, this needs consideration and clarification. I haven't thought 
before of the case that one actually desires to do a new describe of the 
session description of the session currently set up. This case might 
imply that a server needs to know that this request is in the context of 
the given session so it does not move a requesting party around due to 
load balancing, etc. In all other cases it looks like the DESCRIBE can 
be stateless and simply be a tool for requesting session descriptions 
related to a certain media resource. Have you any clarifying thoughts on 
when a session context is needed for a DESCRIBE?

However the use of 302 for load balancing on DESCRIBE and SETUP request 
looks very dangerous. Lets assume that there are two server that are 
both fairly well loaded, what prevents them from sending a requesting 
party back and forth between the server without allowing it to get its 
description or session?

>SETUP, but it does allow Session to be used in DESCRIBE.
Yes, as RFC 2326 is obvious in error and can easily be showed to 
contradict itself, this is not an argument. The valid argument for 
session header in request is simply: Are there reasons when the content 
of a DESCRIBE request is dependent on a already established session? If 
yes, session header shall be allowed  in DESCRIBE, else not.

Best Regards

Magnus Westerlund

---

From: Tom Marshall <[email-masked]>
Date: Wed, 15 Jan 2003 10:16:56 -0800

> would mean that the media stream which the URL in the request points at 

My assumptions are that:

1. The resource description is independent from the resource content.  This
   follows from having a resource description be available via alternate
   means (eg. an HTTP download).

2. The resource description may change while the content does not.  One
   example would be fixing a typo in an i=, e=, or p= line of SDP.

3. The resource content may change while the description does not.  One
   example would be re-encoding a media file with the same codec settings. 
   Another example would be live content.

> description in that case be different while the media is not different. 

See above.

> that a 304 answer does not in fact guarantee the resource description is 

Agreed.  I will state that the 304 response to a DESCRIBE or SETUP does not
imply anything about the response to the other method.

> think that we need to clarify the behavior of reSETUP request that fails.

It will be interesting to see how well this works.  There seems to be a
non-trivial number of combinations of headers and response codes that can be
used with a SETUP request/response.

> >Yes, it would be logical to exclude 304 from the state change in this
> >case.  But wouldn't this break compatibility with 2326?  Are there
> >existing RTSP implementations that would reset the state to Init in this
> >case?
> > 

It is in section A.1: "If a request yields a status code of 3xx, the state
becomes Init, and a status code of 4xx yields no change in state."

This sentence makes it very, very tempting to code the state machine based
solely on the first digit of the status code.  In fact, I think rfc2068
(upon which a large part of rfc2326 is based) encourages this behavior. 
Also note that the error in assuming that all 3xx codes are redirections is
carried over from rfc2068.

I don't know if any existing RTSP state machines behave based solely on the
class of status code, but the concern should be noted.

> when a session context is needed for a DESCRIBE?

I know that in our (RealNetworks) system, the session context is used for a
DESCRIBE.  If you look at past and current versions of our software, you
will see it passed as both an ETag (which is a Session in disguise) and an
actual Session.  This is not to say that the context is needed in the strict
sense, but it is used.  I expect (and hope to motivate) a move away from
using session context in such a manner, but there is one example that has
been in use for several years.

> party back and forth between the server without allowing it to get its 

Nothing prevents this in either HTTP or RTSP.  Most clients will track the
number of redirects received and complain if it is "too many".

> yes, session header shall be allowed  in DESCRIBE, else not.

See above.

-- 
Give a man a fish, and you feed him for a day.  Tell him he should learn how
to fish himself, and he'll hate you for a lifetime.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 16 Jan 2003 16:22:18 +0100

Tom Marshall wrote:

>>>The answer to my question is implied: a 304 response to a SETUP does
>>>      
>>>
>not
>  
>
>>the media stream. In that case it seems valid that the
>>    
>>
>If-Modified-Since 
>  
>
>>header in a request relates to the media stream also. In that case a
>>    
>>
>304 
>  
>
>>would mean that the media stream which the URL in the request points
>>    
>>
>at 
>  
>
>>has not be changed.
>>    
>>
>
>My assumptions are that:
>

Ok.

>>description in that case be different while the media is not
>>    
>>
>different. 
>
>See above.
>
>  
>
>>If that is possible we should point out this fact and explicitly
>>    
>>
>declare 
>  
>
>>that a 304 answer does not in fact guarantee the resource description
>>    
>>
>is 
>  
>
>>still the same.
>>    
>>
>

How do we solve the scenario when a SDP description is distributed with 
HTTP and the client would like to setup this session under the 
assumption that the resource description has not changed in relation to 
the media. Does etags work for this?

In that case I think the proposed clarification works fine.

>>I don't think this problem of overloading is that problematic. I
>>    
>>
>simply 
>  
>
>>think that we need to clarify the behavior of reSETUP request that
>>    
>>
>fails.
>

Yes, there are a couple of questions here. But my direct approach would 
be that a 200 response means that the requested changes has happened. A 
100 answer would mean not yet. A 3xx answer I assume is the same as a 
REDIRECT request for that session, with the possible exception for 304. 
A 4xx would mean that nothing has been changed due to some error in the 
request. A 5xx is usual a little dependent on what has actually 
happened. If the session is still useable at least the parameters shall 
not have been changed.

Which means that a server must basically verify that it can address all 
changes requested in the change before actually performing them.

However I guess that the above idea might not totally fly when one 
starts to look into all details.

>class of status code, but the concern should be noted.

I think the notion of coding the state machine after the first digit is 
actually good one. However in this case it might be needed to either 
clarify the exception or actually move 304 to a new number space like 
6xx. What the general category would actually do is another question.

>I know that in our (RealNetworks) system, the session context is used
>for a DESCRIBE.  If you look at past and current versions of our software, you
>will see it passed as both an ETag (which is a Session in disguise) and
>an actual Session.  This is not to say that the context is needed in the
>strict sense, but it is used.  I expect (and hope to motivate) a move away from
>using session context in such a manner, but there is one example that
>has been in use for several years.
>  
>

Okay, that I guess that we might need to allow session header in 
DESCRIBE request to allow for compatibility. However depending on what 
motivations we can see write some text how it actually shall be used.

>>However the use of 302 for load balancing on DESCRIBE and SETUP
>>    
>>
>request 
>  
>
Okay, I guess that work and does not need fixing. However a note about 
this might be useful. 

-- 

Magnus Westerlund