> >The answer to my question is implied: a 304 response to a SETUP does not > >guarantee that the resource description is unchanged. Correct? > > > > 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. 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. > Assuming that the media stream has not changed, how could a resource > 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. Agreed. I will state that the 304 response to a DESCRIBE or SETUP does not imply anything about the response to the other method. > >I admit that I have not thought about the issue in 513737 before. It > >seems > >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. 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? > > > 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. 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. > 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? 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. > 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? Nothing prevents this in either HTTP or RTSP. Most clients will track the number of redirects received and complain if it is "too many". > >>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. > > > > > > > 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. 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.
Attachment:
pgp00011.pgp
Description: PGP signature