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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Oct 2007 16:02:39 +0200

Hi,

See some the issues addressed. I think the comments regarding the first
sections of the document will be addressed somehow when that part is
rewritten.

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

I have fixed the occurances of RECORD and removed it from the grammar. I
have also updated the text for the SDP directionality attributes. Is the
following text clearer?

The SDP attributes "a=sendrecv", "a=recvonly" and "a=sendonly" provides
instructions on which direction the media streams flow within a session.
When using RTSP the SDP can be delivered to a client using either RTSP
DESCRIBE or a number of RTSP external methods, like HTTP, FTP, and
email. Based on this the SDP applies to how the RTSP client will see the
complete session. Thus for media streams delivered from the RTSP server
to the client would be given the "a=recvonly" attribute.

The direction attributes are not commonly used in SDPs for RTSP, but may
occur. "a=recvonly" in a SDP provided to the RTSP client SHALL indicate
that media delivery will only occur in the direction from the RTSP
server to the client. In SDP provided to the RTSP client that lacks any
of the directionality attributes (a=recvonly, a=sendonly, a=sendrecv)
SHALL behave as if the "a=recvonly" attribute was received. Note that
this overrules the normal default rule defined in SDP [RFC4566]. The
usage of "a=sendonly" or "a=sendrecv" is not defined, nor is the
interpretation of SDP by other entities than the RTSP client.

> 
> 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 have posted the other day on how I have propose to addressed this.
Basically removing the text in section F.

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