> >1. Fill in section 11.3.5 (304 response). Reference section 12.23 and > >12.9. 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? > >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. > > > 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. 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.
Attachment:
pgp00009.pgp
Description: PGP signature