Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt

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

On Dec 1, 2008, at 4:45 AM, Magnus Westerlund wrote:

> > | 16.19.  CSeq
> >
> > I wonder why we have it at all. I assume I must be missing  
> > something. It made
> > sense for rtspu, but now? It is quite trivial to implement for  
> > clients and
> > servers, but not for proxies.
>
> As section 10 says:
>
>    Certain RTSP headers, such as the CSeq header (Section 16.19),  
> which
>    may appear to be relevant only to connectionless transport  
> scenarios
>    are still retained and must be implemented according to the
>    specification.  In the case of CSeq, it is quite useful for  
> matching
>    responses to requests if the requests are pipelined (see Section  
> 12).
>    It is also useful in proxies for keeping track of the different
>    requests when aggregating several client requests on a single TCP
>    connection.

But is it doing anything useful?  HTTP proxies function perfectly  
well without any equivalent.  The rules for RTSP pipelining are the  
same as non-pipelined requests: that responses must be delivered in  
the same order as requests, so there is nothing that the CSeq field  
adds.

I think there is a strong case to be made that CSeq only ever made  
sense for unreliable transports, and there is no value that it adds  
for reliable transports.  While it does not do much harm, it really  
seems to be unnecessary.

joe

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic