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

[Magnus Westerlund <[e-mail]>]

Hi,

Continuing with the issues after Section 11.

Once more a big thanks for the work you have put into this. It is really
helpful, both from clarity point of view and finding some actual
protocol issues.



On 2013-06-06 02:11, Elwyn Davies wrote:

 >
> s13.4.1, para 2:
>> Upon receipt of the PLAY request, the server MUST position the normal
>>    play time to the beginning of the range specified in the received
>>    Range header 
> 
> Should this mention the caveat that (if I understood earlier statements
> correctly) the server may not be able to deliver exactly on this MUST
> and then sets it the nearest it can manage? This is borne out by the
> example later in this section where the server sets the start point back
> 10ms (and says so), etc.  Seek-Style affects the interpreation of MUST!

Yes, I have added that this needs to happen ".. within the limits of the
media resource and in accordance with the Seek-Style header (Section
X.Y) ..".



> 
> s13.4.4/.5/.7/.8: In these sections the Media-Property random access
> property is stated as being required to be Random-Access.  Is
> Conditional Random Access a possible value for this property? The
> confusion in s4.9.1 does not allow me to conclude that this shouldn't be
> a value for the property (sorry for the double negative but this looks a
> bit confused).

These section lists the Media-Properties for the media resource one
request delivery for. Thus from a PLAY request perspective using a
Seek-Style: CoRAP header is fine for the ones that has Random Access
property as Random-Access in these section.


> 
> s13.5.1:  Apologies if this question is stupid - I am not a media stream
> wxpert.  Suppose we have an aggregated stream with (say) a number of
> recorded media items making up the aggregate.  The client sets it on to
> play to the end.  What happens if not all the streams end at the same
> time?  Do we get PLAY_NOTIFY End-of-Stream notifications for each
> individual stream as it ends or just one when the complete aggregate
> ends?

Not at all a stupid question. This should have been clearly specified
for all usages of PLAY_NOTIFY in regards to aggregated sessions. Thus I
have added both a general requirement on PLAY_NOTIFY level:

PLAY_NOTIFY requests MAY use both aggregate control URI and individual
media resource URIs depending on scope of the notification. This scope
may have important distinctions for aggregated sessions, and each reason
for a PLAY_NOTIFY request needs to specify the interpretation and if
aggregated control URIs or individual URIs may be used in requests.

And specified the following for end-of-stream:

For RTSP Session where media resources under aggregated control the
media resources will normally end at approximately the same time,
although some small differences may exist, on the scale of  a few
hundred of milliseconds. In those cases a RTSP session under aggregated
control SHOULD send only a single PLAY_NOTIFY request. By using the
aggregate control URI in the PLAY_NOTIFY request the RTSP server
indicates that this applies to all media resources within the session.
In cases RTP is used for media delivery corresponding RTP-Info needs to
be included for all media resources. In cases where one or more media
resource has significantly shorter duration than some other resources in
the aggregated session the server MAY send end-of-stream notifications
using individual media resource URIs to indicate to agents that there
will be no more media for this particular media resource related to the
current active PLAY request. In such cases when the remaining media
resources comes to end-of-stream they MUST send a PLAY_NOTIFY request
using the aggregate control URI to indicate that no more resources remains.

And the following for Media-Properties-Update

The Media-Properties header has session scope, thus for aggregated
sessions the PLAY_NOTIFY request MUST be using the aggregated control URI.

And for Scale-Change

PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated
control URI in the request. The scale change for any aggregated session
do apply to all media streams part of the aggregate.



> 
> s13.5.2, para 2:
>> that changes the basis for making
>>    estimates on how the media range progress. 
> I can't parse the last part of this and I am not sure what it should be.

I hope this is better

This notification MUST be sent for media that are Time-Progressing every
time an event happens that changes the basis for making estimates on how
the available for play-back media range will progress with wall clock time.


> 
> s14: What happens if the upper layer PDU is longer than (2^16 - 1)?

I have added this note:

Note that this mechanism does not support larger PDUs than 65535 bytes,
which is the same that regular IPv4 and IPv6 is capable. If the media
delivery protocol intended to be used has larger PDUs than that, the
definition of such mechanisms usage of this mechanism will require the
definition of a PDU fragmentation mechanism.



> 
> s18.10, private para:  Is there any way in RTSP for the cache to know
> whether this is a private cache for the user that should cache this
> content?

To my understanding this is something the cache itself knows through its
behavior and deployment.


> s18.10, last para:  I am not absolutely certain, but I think this para
> is specific to the max-age cache type rather than being generic as
> implied by the indentation. [If so use the <vspace blankLines=1/> trick
> to provide a pseudo-paragraph break]

Yes, you are correct. I did the equally easy choice for hanging lists to
simply make a new paragraph without any paragraph text.

> s18.14: Consider adding the 'identity' value explicitly to the ABNF.

If I understand you correctly what you are requesting is that "identity"
is listed as an construct in the content-coding ABNF construction that
are used by Accept-Encoding and Content-Encoding headers.

Accept-Encoding   =  "Accept-Encoding" HCOLON
                     [ encoding *(COMMA encoding) ]
encoding          =  codings [SEMI accept-params]
codings           =  content-coding / "*"
content-coding    =  "identity" / token
Content-Encoding   =  "Content-Encoding" HCOLON
                      content-coding *(COMMA content-coding)


> 
> s18.29, para 2: Are (or should there be) constraints on the ordering of
> media ranges for a non-continuous media stream?  It would probably make
> the client's job easier if they were in incresing order. 

This is a interesting question. If one simply expresses what pieces of
media that are currently available then using a requirement that the
first ranges end-time must be prior any of the subsequent ranges start
times would work. However, my head gets stuck on considering when
desired playback is non linear. But that is probably a higher function
question.

So a possible addition after this existing sentence:

The server MAY include more than one range specification of any given
time format to indicate media that has non-continuous range.

would be:
The range specifications shall be ordered with the range with the lowest
value or earliest start time first, followed by ranges with increasingly
higher values or later start time.

Comments on this?

> s18.41: It appears from a literal interpretation (the third sentence is
> an unqualified MUST) that the responder has to respond with error code
> 551 and an (empty?) list of Unsupported features if it actually does
> support all the features.  I suspect this is not what is wanted.

Correct, reformulated proposal is:

In case any of the feature-tags listed by the Require header are not
supported by the server or client receiving the request, it MUST respond
to the request using the error code 551 (Option Not Supported) and
include  the Unsupported header listing those feature-tags which are NOT
supported.

> s18.45, para 4: Harummph! Political Correctness strikes again.  Every
> protocol should (and probably does) have a CRAP policy. ;-)

Yes, the lower case o is silent here ;-).


> 
> s18.52, 'setup' section:  There seems to be some inconsistency in the
> spcification of the 'active/passive/actpass' values.  a) Is there some
> reason for specifying them in square brackets?

Not, that I can remember. Removing both brackets and quotes.

 b) should they say
> ["active:"] or ["active":] - both formats are used?  The ABNF has the
> plain words with no brackets or quotes.

The later would be correct, but now it will only say
active: <description>

The ABNF is clear that it will be
RTP/SAVPF/TCP;unicast;setup=active;connection=new


> 
> 18.52, 'connection' section, 1st line:
> s/Clients use the setup parameter/Clients use the connection parameter/
> (I assume).

Had to tweak that sentence a bit more:

Clients use the connection parameter in a transport specification part
of the Transport header in a SETUP request, to indicate the client's
preference for either reusing an existing connection between client and
server (in which case the client sets the "connection" parameter to
"existing"), or requesting the creation of a new connection between
client and server (in which cast the client sets the "connection"
parameter to "new").



> 
> s21.1, transfer of sensitive info: Is there an equivalent of the Referer
> header in RTSP?  Not sure there is but it would be good to explain one
> way or the other (either there isn't one so it's less of a problem or
> this is the equivalent...)

Yes, the Referer header is retained also in RTSP.


> 
> s21.1, DNS Spoofing:  Presumably RTSP will interact significantly with
> content delivery networks.  Some of these work by DNS 'spoofing' that
> was in its infancy when RFC 2616 was published.  Are there any other
> issues that come out of the greater prevalence of CDNs since 1999?

I have no experience with large scale deployment of RTSP. To my
knowledge there hasn't been the same development with CDNs for RTSP as
HTTP. This I think is dependent on several factors. One has been the
issues with deploying RTSP on global scale due to NAT traversal etc,
instead progressive download and HTTP adaptive streaming has mostly
taken this market. Thus most large scale deployments has been in
contexts within single operators providing Video On Demand services etc.

Thus, I don't really know of any additional issues around this.


> 
> s21.1, Session Hijacking:  The last part of this is written so that it
> appears to mandate authentication in all cases.  As far as I understand
> it is up to the client to decide if it needs authentication etc and some
> content will be offered on unsecured URIs.  I think this needs to be
> clearer that authentication will mitigate the problem but whether it is
> done is up to the client if the server doesn't care.

Is this better?

Another choice for preventing session hijacking is to use client
authentication and only allow the authenticated client creating the
session to access that session.

> 
> s21.1, Persistently suspicious behaviour:  There seems to be a mismatch
> between the title (persistently..) and the first sentence (a single
> instance).  Do we have examples of the sort of security risk which is
> supposed to be met with a 403 response the first time?

Yes, it is a bit inconsistent. I propose:

Suspicious behavior: RTSP servers upon detecting intances of behavior
which is deemed a security risk SHOULD return error code 403
(Forbidden). RTSP servers SHOULD also be aware of attempts to probe the
server for weaknesses and entry points and MAY arbitrarily disconnect
and ignore further requests from clients which are deemed to be in
violation of local security policy.



> 
> s21.1, last sentence:
>>    Some of the above threats are such that
>>    the implementation of the RTSP functionality itself needs to consider
>>    which policy and strategy it uses to mitigate them.
> It strikes me that this is not very helpful to a prospective
> implementer.  The point of this section is at least in part to provide
> that policy and strategy.  I am not quite sure how to rewrite this (or
> if indeed other people think it does need rewriting). 

No, it is not helpful in other ways then, you need to think about this
and consider what mitigations you think should be implemented and how
that affects your implementation design.

For now I am leaving this as it is.



> s22.3:  The rules about allocating in the sections above x50 should be
> explained here (see s8.1.1).  The  numbers below x50 in each section
> should be marked as a special category of reserved so they are only
> allocated to HTTP analogues.  Is an experimental/private segment in each
> category desirable?   

Yes I think adding something like the below to at least make clear the
intention that RTSP specific status codes should first be registered in
the x50-x99 range.

New RTSP functionality requiring Status Codes should first be registered
in the range x50-x99. Only when the range is full should registrations
be done in the x00-x49 range, unless it is to adopt an HTTP extension
also to RTSP. The reason is to enable any HTTP extension to be adopted
to RTSP without needing to renumber any related status codes.


Regarding experimental and private I am very torn about such range.
Unless someone else in the WG thinks this is worth the work I will leave
it out.

> 
> s22.9: Being allowed to register new Range header formats will currently
> be restricted to times specified by NPT, SMPTE or UTC because no
> registry is defined for Accept-Ranges.  Is this what is intended?

No, the intention is that Range header format registry is shared between
Range and Accept-Ranges. However, I see the description is not clear on
this and needs to be amended.

I have sent a separate email on this.

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