> >1. When 304 is sent in response to a DESCRIBE, what exactly is meant by > >"not modified"? > > 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. 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? > > 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 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. > >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? > > > > > 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? 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? > >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? > > > > > 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). 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 > (See table 4). 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. -- 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.
Attachment:
pgp00010.pgp
Description: PGP signature