Subject: [MMUSIC] draft-ietf-mmusic-rfc2326bis-14.txt

From: Joe Pallas <[email-masked]>
Date: Tue, 2 Jan 2007 14:10:31 -0800

A few remarks on the changes in this draft:

Section 2.2 doesn't have any major changes, but, to complement the  
change to the description of "Live" in section 1.4, it may be useful  
to add something about seekable live content, such as:

	In some cases, the server providing live content may be saving some  
or all
	of the material to allow clients to pause the stream and resume it  
from the paused
	point, or to "rewind" and play continuously from a point earlier  
than the live point.
	Hence, this use case does not necessarily exclude playing from other  
than the
	live point of the stream, playing with scales other than 1.0, etc.

Section 2.5 seems to mostly say that RTSP 2.0 is not likely to be  
useful in this case without extensions.  Perhaps it shouldn't say  
much more than that.

Section C.1.5 on SDP attributes sendrecv, recvonly, and sendonly is  
confusing.  In particular, the mention of '"PLAY" mode' is odd, since  
RECORD mode is explicitly undefined, so PLAY mode is the only mode  
defined.  For that matter, why isn't "RECORD" removed from the  
grammar for mode -- is there some value to making it reserved but  
undefined?  Also, section 13.4.2 mentions the RECORD request, which  
no longer exists.

Section F introduces new language on the interpretation of CR and LF  
for backward compatibility.  The language in RFC2326 was a bad idea,  
since it can be paraphrased as "Receivers should be prepared for  
senders to violate this specification."  While this is always true,  
putting it into the specification itself is unwise, as it appears to  
give license to violators.  That said, the language that was added to  
section F uses the word "should" in a dangerous way.  The new  
instruction raises doubts about the correct interpretation of  
sequences like CR LF LF, LF CR, and CR CR LF.  If there are, in fact,  
any RTSP 1.0 clients still extant that take such liberties, maybe it  
would be best to pretend they don't exist.

Hope this is useful.
joe

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic