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

[Magnus Westerlund <[e-mail]>]

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?

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.

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


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

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

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

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



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


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


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

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

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

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



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

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

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


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

We do have Media-Properties header to provide more details for what
specific media transformations a server can do when the support play.scale.

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