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

[Magnus Westerlund <[e-mail]>]

Hi,

Now getting to implement your response in our source.

Some few additional comments or notes below.

On 2013-06-25 14:47, Elwyn Davies wrote:
> 
> 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:




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

I think your suggestion is a good one and I have written such a section,
initial proposal below:

4.4.  Media Time Formats

   RTSP currently supports three different media time formats defined
   below.  Additional time formats may be specified in the future.
   These time formats can be used with the Range header (Section 18.38)
   to request playback and specify at which media position protocol
   requests actually will or has taken place.  They are also used in
   description of the media's properties using the Media-Range header
   (Section 18.29).  The format identifier only are used in Accept-
   Ranges header (Section 18.5) to declare supported time formats and
   also in the Range header (Section 18.38) to request the time format
   used in the response.

4.4.1.  SMPTE Relative Timestamps


Regarding the SDP a=range attribute. The ABNF allows the unqualified
usage. The textual specification of a=range attribute in D.1.6 is silent
on unqualified usage.

The only usage of unqualified usage in a=range would be to indicate that
although this media has unknown or time-progressing properties it does
support the time formats for the a=range with unqualified values that
has been included.



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

It was sent to the MMUSIC WG mailing list on the 24th of June. I have
forwarded if to you personally.

> 
>>
>>>
>>> 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)]).' 

Yes, I added such text.


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

This has gotten changed a bit more and currently reads:

A more complex case may arise when a load balancing RTSP proxy is in
use, i.e., where an RTSP proxy is used to select amongst a set of RTSP
servers to handle the requests, or when multiple server addresses are
available for a given server name. The proxy or client may receive a 503
(Service Unavailable) or 553 (Proxy Unavailable) from one of its RTSP
servers or proxies, or a TCP timeout (if the server is even unable to
handle the request message). The proxy or client simply retries the
other addresses or configured proxies, but may also receive a 503
(Service Unavailable) or 553 (Proxy Unavailable) response or TCP
timeouts from those addresses. In such a situation, where none of the
RTSP servers/proxies/addresses can handle the request, the RTSP agent
has to wait before it can send any new requests to the RTSP server. Any
additional request to a specific address MUST be delayed according to
the Retry-After headers received. For addresses where no response was
received or TCP timeout occurred, an initial wait timer SHOULD be set to
5 seconds. That timer MUST be doubled for each additional failure to
connect or receive response until the value exceeds 30 minutes when the
timers mean value may be set to 30 minutes. It is REQUIRED 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.
> 
> 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!

After my leave I have written a bit of definition for play.basic:

11.1.  Feature Tag: play.basic

   The play.basic feature tag represents an RTSP implementation
   according to all normative RTSP protocol features specified in this
   specification.  This specification is both a RTSP core specification
   as well intended to enable setup and control of playback of media.
   Thus following all normative parts in the main sections (the ones
   with numbers), not the appendices (starting with letters), unless
   explicitly specified in a main section for being a required appendix.

      Note: This feature tag does not mandate any media delivery
      protocol, such as RTP.

      In RTSP 1.0 there was a minimal implementation section.  However,
      that was not consistent with the rest of the specification.  So
      rather than making an attempt to explicitly enumerate the features
      for play.basic this specification have to be read in completeness
      and the necessary features normatively defined as being required
      are included.

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

Yes, I have tried to make it clear that it is not resource specific.

   Supported:  This header is used to determine the complete set of
         functionality that both client and server have in general and
         is not dependent on specific resource.  The intended usage is
         to determine before one needs to use a functionality that it is
         supported.  It can be used in any method, but OPTIONS is the
         most suitable one as it at the same time determines all methods
         that are implemented.  When sending a request the requester
         declares all its capabilities by including all supported
         feature-tags.  This results in the receiver is learning the
         requester's feature support.  The receiver then includes its
         set of features in the response.

   Proxy-Supported:  This header is used similarly to the Supported
         header, but instead of giving the supported functionality of
         the client or server it provides both the requester and the
         responder a view of the common functionality supported in
         general by all members of the proxy chain between the two
         supports and not dependent on the resource.  Proxies are
         required to add this header whenever the Supported header is
         present, but proxies may also add it independently of the
         requester.

I also added variations of this sentence to the Supported and
Proxy-Supported headers description:

These feature tags are the ones the server or client support in general,
and is not specific to the request resource.

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

Doesn't really work as supported is intended to be possible to add to
any request to determine the functionality supported by the replying agent.

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