Hi Tom, Some comments Tom Marshall wrote:
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.and1. Fill in section 11.3.5 (304 response). Reference section 12.23
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?
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:
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 requestI 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?
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 theThe 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).
server returns 302 instead. What happens to the session, and should the
server stop sending data packets?
Yes, I think you are correct, just had some problem remembering that.
applies2. Modify 10.10 (REDIRECT) to clarify the following behavior:
If a REDIRECT contains a Session: header, it is end-to-end and
(tcp)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
thatconnection.The last sentence about a REDIRECT's applicability to the control connection I can't remember discussing. However I do agree with you
it is a logical step to move the control connection. If a server is totally shutting down it will anyway need to close the TCPconnections,
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.