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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Apr 2007 17:29:44 +0200

Hi Joe,

Thanks for the comments. Sorry I haven't responded before. But now that 
we actually are going somewhere with RTSP it seemed a good time to 
actually respond.

Joe Pallas skrev:
> 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.

I agree that there are servers that has this functionality. However I 
think we may need to consider how we indicate the properties of streams. 
We maybe need at least three categories: On-demand, Live, Recorded-Live.

> 
> 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.
> 

I am not agreeing with that classification. There is primarily a warning 
about some serious security issues. However they do not apply in all 
deployements.

> 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.  

I think we need to consider how these rules apply for "PLAY" mode. 
However not being clear that we are talking about "PLAY" seems a bit 
strange. But I am on the other hand convinced that the text can be 
improved as this is the first shot at the text.

> For that matter, why isn't "RECORD" removed from the grammar 
> for mode -- is there some value to making it reserved but undefined?  

This should be fixed. The "mode" parameter anyway need an extension so 
keeping something for the future when it can easily be re-instate when 
the rest of the definition exist seems fine.

> Also, section 13.4.2 mentions the RECORD request, which no longer exists.

Needs to be fixed.
> 
> 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.
> 

I don't know how common it is these violations are. It might be easier 
to leave this alone by removing the paragraph.

> Hope this is useful.

Definitely

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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