Subject: Re: [MMUSIC] WGLC on RTSP 2.0 - draft-ietf-mmusic-rfc2326bis-23.txt

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 28 Jun 2010 11:28:06 +0200

Sean,

Here we go with your comments:

> -----Original Message-----
> From: Sean Sheedy [mailto:[email-masked]]
> Sent: Saturday, April 24, 2010 5:51 PM
> To: Martin Stiemerling
> Subject: Fwd: Re: [MMUSIC] WGLC on RTSP 2.0 - draft-ietf-mmusic-
> rfc2326bis-23.txt
> 
> Martin,
> 
> I sent this in to the mailing list yesterday morning, but it is stuck
> in the pipeline waiting for moderator approval due to the size of the
> attachment.  So I figured I'd send it on directly to you.
> 
> Best regards,
> Sean
> 
> 
> -------- Original Message --------
> Subject: 	Re: [MMUSIC] WGLC on RTSP 2.0 - draft-ietf-mmusic-
> rfc2326bis-23.txt
> Date: 	Fri, 23 Apr 2010 10:41:29 -0700
> From: 	Sean Sheedy <[email-masked]>
> <mailto:[email-masked]>
> Organization: 	ARRIS, Inc.
> To: 	MMUSIC Working Group <[email-masked]> <mailto:[email-masked]>
> 
> 
> 
> My comments:
> 
> Section 9.1.
>         The text refers to "Message-body headers", but the the grammar
>         syntax uses the token "message-header".  Changing the token to
>         "message-body-header" would be more consistent.

True and fixed. 9.1 reads really confusing with this mix. 

> 
> Section 10.5.
>         The last paragraph contains:
>                 (see below and Appendix B)
>         It was not clear to me where "see below" meant to direct me.

Yep, this "see below" is a left-over and I have removed it. 

> 
> Section 13.4.1.
>         The fourth paragraph begins:
>                 If a client request starting playing media at the
>                 end-point either explicitly with a Range header or
>                 implicitly by having a pause point that is at the end
> of
>                 the media, a 457 (Invalid Range) error MUST be sent and
>                 include the Media-Range header (Section 16.29).
>         I believe that "end-point" in this context is incorrect.  An
>         alternate suggestion:
>                 If a client requests to start playing at the end of
>                 media, either explicitly with a Range header or
>                 implicitly with a pause point that is at the end of
>                 media, ...
>         Also, the MUST here conflicts with the SHOULD two paragraphs
>         later.

Fixed.

There are also some other occurrences of "end-point" in that section that do refer to "end of the range" and not the client/server end-point (for which end-point is used in other parts of the documents). This should instead read "stop point", as used in Section 16.38 "Range"
Also Fixed.

> 
> Section 13.4.3.
>         This section doesn't appear to address what, in my experience,
>         is the most common use of a PLAY request while in the Play
>         state: changing the Scale and continuing from the current
>         playout point (i.e., entering or leaving fast forward or
>         rewind).  Similarly, this section doesn't address changes to
>         Speed during Play state as described in section 2.5.1.  This
>         could be handled by defining any of the following as signaling
> a
>         total replacement:
>               * An explicit start position in the Range header;
>               * A Scale change;
>               * A Speed change.

I have added text for fast forward (as one example for changing the scale), but I couldn't understand the second part of your comment.

> 
> Table 7
>         "object" is missing from the "TEARDOWN S->C" row.  Section
>         13.7.2 implies that the value might be "P,S", but only
> discusses
>         the session aggregate case.  I see little use for
>         server-initiated TEARDOWNs of individual media streams, but the
>         document should be clearer about whether they are allowed, and
>         this should be reflected in Table 7.

Added that TEARDOWN S-> can operate only on aggregates to 13.7.2. add reflected this in Table 7 (P).
I also see little use of server TEARDOWN for individual media streams. However, I will put this on my discussion list for the next IETF meeting.

> 
> Table 8
>         "TEARDOWN S->C" is missing completely.  "object" will need to
> be
>         consistent with the entry in Table 7.

Fixed. 

> 
> General:
>         Naming conventions are inconsistent for states.  For example,
>         the Play state is at various points referred to as:  Play,
> PLAY,
>         play, and PLAYING.  The document should consistently use the
>         names from the state tables in Appendix B.4:  Init, Ready, and
>         Play.

Ok, went through the draft and have hopefully caught all state names.

> 
>         "Unmutable" is used instead of "Immutable" for Media-Properties
>         in several locations.

Fixed.

> 
>         I agree with Wolfgang's and Martin's skepticism toward the Via
>         header.

Will pack this also in the slide set for upcoming MMUSIC session at the IETF.

> 
> 
> I've attached diff output against draft-ietf-mmusic-rfc2326bis-23.txt
> ("diff -ub") with suggested grammar, punctuation, etc., changes, none
> of
> which should alter the meaning of the text.

Ok, I will go through them, but do not acknowledge here the particulars changes applied. 

Thanks!

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014