Re: [MMUSIC] RFC2326bis-22, Section 16.19 need clarification.

[Joe Pallas <pallas at cs.stanford.edu>]

Once again I will assert that CSeq is both unnecessary and, as we see  
from this discussion, confusing.  It should be removed.  (Some  
replacement may be needed for the Request-Status header of  
PLAY_NOTIFY, however. The existing NOTIFY extension used with RTSP 1.0  
does not have an equivalent, so it's not clear it is necessary.)

To recap:
1. CSeq was originally included in RTSP 1.0 to support unreliable  
protocols such as UDP.
2. UDP support in RTSP 1.0 was never fully specified and no one has  
claimed to have an implementation.
3. RTSP now explicitly assumes a reliable, connection-oriented stream  
protocol such as TCP.
4. CSeq serves no purpose with a reliable transport layer.
5. HTTP seems to have achieved a modest degree of success in the  
field, including proxy support, without any equivalent to CSeq; it  
uses transport connections to distinguish conversations.

The only argument I've heard for keeping CSeq is backward  
compatibility with existing implementations.  I don't think that's  
very strong, because the draft explicitly denies compatibility with  
RTSP 1.0.  For it to matter, there would need to be an existing  
implementation that assumes responses can arrive out of order and  
relies on CSeq to match responses to requests.  Does anyone know of  
such?

If we really can't remove it, can we at least deprecate it—include  
some text that clearly informs the reader that CSeq has no meaning and  
should not be relied upon for anything?  The rules would be something  
like this: CSeq is not required on a request. If a server receives a  
request with CSeq, it must include CSeq in the response.

joe