Re: [MMUSIC] [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Elwyn Davies <[e-mail]>]

Hi, Magnus.

Thanks for the (continuing) responses.

Some comments in line.

I look forward to the updated document!

/Elwyn

On Mon, 2013-06-24 at 16:51 +0200, Magnus Westerlund wrote:
> Elwyn,
> 
> Follow up on some of the nits that is not simply to implement or where I
> disagree or want to provide feedback.
> 
> This email covers all issues up to and including Section 11. That is as
> far as I have managed to process them yet. I will now handle over the
> rest of this list to my co-authors.
> 
> On 2013-06-06 02:11, Elwyn Davies wrote:
> > 
> > s2.3, para 5:
> >> The server should also regularly send every 5
> >>     minutes the current media range in a PLAY_NOTIFY request.
> > Shouldn't this be configurable?
> 
> As discussed in Section 13.5.2 the reasons for the picked time is the
> following:
> 
>       The recommendation for sending updates every 5 minutes is due to
>       any clock skew issues.  In 5 minutes the clock skew should not
>       become too significant as this is not used for media playback and
>       synchronization, only for determining which content is available
>       to the user.
> 
> Yes, it can be configurable, and in fact 5 min is only the recommended
> interval. So, if an implementation that have a good reason for something
> else can do that. Do you have a reason why you think this should be
> configurable?
Standard review reaction to an apparently sensible but arbitrary fixed
parameter!  
> 
> But, if it should be rewritten, I think the acceptable range for within
> to adjust it should be specified, like between 1 min and 2 hours.

Suggest:
- adding 'approximately' ('send approximately every') and a ref to
s13.5.2 to s2.3. 
- change s13.5.2:
OLD:
   In addition it is
   RECOMMENDED that the server sends these notifications every 5 minutes
   for time-progressing content to ensure the long-term stability of the
   client estimation and allowing for clock skew detection by the
   client. 
NEW:
   In addition it is
   RECOMMENDED that the server sends these notifications approximately 
   every 5 minutes
   for time-progressing content to ensure the long-term stability of the
   client estimation and allowing for clock skew detection by the
   client.  The time between notifications should be greater than 1 minute 
   and less than 2 hours.

> 
> > 
> > s2.3, last para:
> >> If the client waits too long
> >>     before resuming the pause point, the content may no longer be
> >>     available.  In this case the pause point will be adjusted to the end
> >>     of the available media.
> > I know this is a subjective choice, but I would have thought adjusting 
> > to the beginning of the available media would be what the user expects.
> > Later: Having read s13.4.1, I think this conflicts with (or is unclear) 
> > compared with s13.4.1, para 2 which states that the pause point will be
> > the oldest retained time - that is what I would have expected.
> 
> Yes, "end" in the above sentence is not quite right. My proposal is the
> following:
> 
> In this case the pause point will be adjusted to the closest point in
> the available media.
> 
Seems like a good choice.
> 
> > 
> > 
> > s3.1, para 3:  Clearly there won't be any smaller type paras in the 
> > ASCII version.. is there a PDF version that actually has smaller type?  
> > The one I get from the repository doesn't seem to have any smaller type 
> > paras.
> 
> I removed the "small type" as this is a remains from when the draft was
> produced using LaTex and a PDF version was produced.

Fine.

> 
> > 
> > s4.4: An external reference to the relevant Society of Motion Picture 
> > and Television Engineers standard (probably SMPTE 12M) ought to be 
> > included to define things like "SMPTE 30 drop".  [Aside: 29.97 frames 
> > per second?? Must be something to do with Never Twice the Same Color.  
> > Oh, well,  a little research job for whan I am really bored.]
> 
> Yes, it is ST 12M-1 2008 that appears to be the relevant reference. Yes,
> SMPTE 30 drop is a NTSC thing.

:-)

> 
> > 
> > s4.9.1: There seems to be some confusion in this section between the
> > values from the Seek-Style header and the values from the
> > Media-Properties random access property.  The section says the values
> > are from Seek-Style but they are actually from the random access
> > property.  Presumably there was some intention to interelate the media
> > capabilities and the play event policies?  Further this section has
> > Random Access, Conditional Random Access, Return to Start and No
> > Seeking.  This doesn't match exactly with either Seek-Style (RAP, CoRAP,
> > First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only
> > and No-Seeking).
> 
> Yes, this was confused. Actual the Media-Properties headers values are a
> distinct set. Then if doing random access then the Seek-Style policies
> applies. This I propose to clarify by writing Section 4.9.1 as:
> 
> 4.9.1.  Random Access and Seeking
> 
>    Random Access is the ability to specify and get media delivered 
>    from any point inside the content, an operation called seeking.  The
     ^^^^^^^^^^^^^^^^^^^^^
Try: starting from any time instant within

>    Media-Properties header will indicate the general capability for a
>    media resource to perform random access.  If random access is
>    possible the actual behavior policy when seeking can be controlled
>    using the Seek-Style header (Section 18.45).
> 
>    Random-Access:  The media is seekable to any out of a large number of
>       points within the media.  Due to media encoding limitations, a
>       particular point may not be reachable, but seeking to a point
>       close by is enabled.  A floating point number of seconds may be
>       provided to express the worst case distance between random access
>       points.
> 
>    Beginning-Only:  Seeking is only possible to the beginning of the
>       content.
> 
>    No-seeking:  Seeking is not possible at all.
> 

Generally fine - small suggestion above.

> 
> > s4.9.x: It would be desirable to use the parameter names in the same 
> > form as they appear in s18 (e.g., Random-Access instead of Random 
> > Access, No-Seeking instead of No seeking) both in the definitions 
> > (s4.9.1 - s4.9.4) and the mapping (s4.9.5).
> 
> Yes, that is has been addressed.
> 
OK

> > 
> > 
> > ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified 
> > values "smpte", "npt" and "clock" are valid  in the Range parameter.  
> > What is the meaning of such an unqualified value?
> 
> You are correct about that the basic definition in ABNF allows for
> empty. The reason for this is the following stated in Section 18.38:
> 
>     It MAY be
>    included in GET_PARAMETER requests from the client to the server with
>    only a Range format and no value to request the current media
>    position, whether the session is in Play or Ready state in the
>    included format.
> 
Two points:
- A suggestion: Make ss4.4/4.5/4.6 into subsections of a new s4.4.  Add
a bit of text in the new s4.4 saying that the range specifiers are used
in the RANGE header and pointing to s18.38 for the unqualified use.
(consistent with s2.7 which gives usage).
- An issue I hadn't spotted: I haven't checked but are the unqualified
values allowed in the SDP extension case (s20.3)?
> 
> 
> > 
> > s5:  It would be sensible to note that the ABNF fragments in s5 and the 
> > following sections match with the full syntax productions in s20.
> 
> I have added a note, but they are in fact equivalent, but not identical.
> Thus I make it clear that that this is for information and the formal is
> in section 20.2.2.

OK

> 
> 
> > 
> > Table 3:  Proxy-Authorization (Section 18.34) doesn't appear in any of 
> > the various header categorization tables [I must have better things to 
> > do than checking they were all there :-( ].  I think it belongs here.
> 
> Sorry, for not having found this myself before. You noticing it missing,
> was actually a larger inconsistency issue. It was missing in the ABNF also.

(I think I noted that later).

> 
> I have spent quite some time now to ensure that the ABNF, the tables in
> Section 6-8 and the header description now align as they should
> regarding category.

Yes.. tedious job as I found out! Good!

> 
> 
> > s8.1.1, code 505:  HTTP code 505 is explicitly '*HTTP* version not 
> > supported' - should there really be a separate code for 'RTSP version 
> > not supported'?
> 
> Yes, but the import of HTTP response codes are their meaning not there
> exact definition. Thus 505 is RTSP version not supported as listed in
> table. That is also what section 17.5.6 defines it as.

I won't push this one.

> 
> > 
> > s9: Is it deliberately left vague as to whether other message types 
> > might have message bodies?
> 
> This is unnecessary vague. In attempt to clarify this I have proposed
> the following rewrite of that paragraph:
> 
> The SET_PARAMETER and GET_PARAMETER request and response, and DESCRIBE
> response is by this specification defined that they MAY have a message
> body and its purpose. All 4xx and 5xx responses MAY also have a message
> body to carry additional response information. A message body MAY occur
> on any RTSP 2.0 request or response, but the content of the message body
> MAY be ignored. Extensions to this specification can specify the purpose
> and content of message bodies, including requireing their inclusion.

Seems sensible. Editorial update:
The SET_PARAMETER and GET_PARAMETER requests and responses, and the
DESCRIBE response as defined by this specification MAY have a message
body; the purpose of the message body is defined in each case. All 4xx
and 5xx responses MAY also have a message body to carry additional
response information. Generally a message body MAY be attached to any
RTSP 2.0 request or response, but the content of the message body
MAY be ignored by the receiver. Extensions to this specification can
specify the purpose and content of message bodies, including requiring
their inclusion.
> 
> 
> > 
> > s10.2, para 6 and following note:  I can't see that the note following 
> > para 6 can be justified: since the restriction on multiple connections 
> > from a client to a server is only a SHOULD, an interoperable server MUST 
> > be capable of handling multiple connections from a client unless the 
> > server can explicitly send back a TOO MANY CONNECTIONS status.
> 
> See separate email

Should I have had this already?

> 
> > 
> > s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... 
> > should these be carried over into RTSP?  The IANA registry says they are.
> 
> I am uncertain what you want here? Yes, the URI format allows for future
> definitions of literal IP address versions. However, RTSP does contain
> explicit IPv4 and IPv6 address fields that aren't URIs. Thus, future IP
> versions will require some extension definition to function.

Perhaps an excess of zeal on my behalf.  Perhaps a (non-normative) note
saying what you just wrote: 'Although the general URI format envisages 
potential future new versions of the literal IP address, usage of any
such new version would require other modifications to the RTSP
specofication (e.g., ...[any relevant section(s)]).' 
> 
> 
> 
> > s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED 
> > here are usually MANDATORY. (Also applies to wait timer in last para of 
> > this section).
> 
> Yes, I agree that they usually are. I personally have no issues making
> them required. I think the Recommended formulation is really one of
> these cases, do this or something even better or you will hang yourself
> to be a bit blunt.
> 
> But, if I understand you, you think this paragraph should read:
> 
> An RTSP server or proxy in an overload situation must select the value
> of the Retry-After header carefully and bearing in mind its current load
> situation. It is REQUIRED to increase the timeout period in proportion
> to the current load on the server, i.e., an increasing workload should
> result in an increased length of the indicated unavailability. It is
> REQUIRED to not send the same value in the Retry-After header to all
> requesting proxies and clients, but to add a variation to the mean value
> of the Retry-After header.
> 
> Objections to this?

I was only really concerned about the variation.  I would leave the 'how
much to increase' as a RECOMMENDED, but say there MUST be variation in
the retry values sent to different clients if theye are sent at all.

> 
> > 
> > s10.7, last para: Should the doubling of the wait timer have an upper limit?
> 
> Yes, I added an upper limit of 30 minutes. This is way beyond what any
> human will accept, only robots will keep on going at this timeout value.
> And I think that is large enough to avoid any issues.

Agreed

> 
> I also propose to clarify the range for the variations and added the
> classical 0.5 to 1.5 times the deterministic value.
> 
> Text proposal.
> 
> That timer MUST be doubled for each additional failure to connect or
> receive response until the value exceeds 30 minutes when the timers
> deterministic value may be set to 30 minutes. It is RECOMMENDED to not
  ^^^^^^^^^^^^^
  base?
> set the same value in the timer for each scheduling, but instead to add
> a variation to the mean value, resulting in picking a random value
> within the range of 0.5 to 1.5 of the mean value.
> 
> > 
> > s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
> > are 'defined' in this draft.  The nearest thing to a definition of
> > play.basic that I can find is the last sentence of para 4 in this
> > section.  I am not convinced that I could produce an interoperable
> > implementation of a server with this feature-tag with the one sentence
> > 'definition'.  References to where play.xxx are defined would be useful
> > (play.scale in s18.44, play.speed in s18.48).
> > 
> 
> Hmmm, the other feature-tags than play.basic are pretty straightforward
> and well contained. play-basic is really a minimal RTSP server
> implementation according to the whole spec for media playback.
> 
> This can probably be more clearly expressed somewhere, but it can't
> really be enumerated. Then we are back to the issue we had with RFC 2326
> minimal implementation list that was incomplete and lacked a lot of
> things really necessary.
> 
> This issue still haven't resulted in any changes to our source.

Ah!  I see I have (re-)opened a can of worms!  One thought for providing
the proverbial larger can into which the worms can be stuffed back:

Define 'play.basic' as the default that you get back if none of the
others apply.  How's that for weasel words!
> 
> 
> > s11, Supported (and Proxy-Supported) bullets: 
> > OLD:
> >          This results in the
> >          receiver is learning the requester's feature support.
> > NEW:
> >          This results in the
> >          receiver learning the requester's feature support 
> >          relevant to the specified resource.
> > [Note: I added 'specified resource' here and then thought about whether
> > this made any sense.  It probably needs to be clearer what set of
> > features are included in the Supported list for both requester and
> > responder.  Are they restricted to those relevant to the specified
> > resource that might of course be the whole server, proxy - or client?? -
> > in which case there isn't an issue, but it might be a specific
> > presentation - what happens then?  Affects s13.1, para 3 also.]
> 
> Actually, I don't think it is specific to the media resource. The issue
> with making it specific to a media resource is that a RTSP client needs
> to be able to look into the future and supply an answer for a media
> resource it may not yet know sufficient to provide a tailored response
> for. I think it is simpler and better to provide general capabilities in
> the supported header and then later determine how well they apply for
> the media resource itself.

So maybe make it clear that feature support returned is just what the
responder can do generally and is not specific to the URI provided.

Either that or make the request valid only for non-specific URIs (i.e.
at the server/client level) if that is possible (not sure how that would
work for server asking client if that is allowed).
> 
> We do have Media-Properties header to provide more details for what
> specific media transformations a server can do when the support play.scale.

Right.


/Elwyn

> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art