[MMUSIC] Comments on draft-pthatcher-mmusic-rid-00

[Paul Kyzivat <[e-mail]>]

Here are some comments on draft-pthatcher-mmusic-rid-00 that I made 
during my initial reading:

* Section 6:

All of the parameters mentioned pertain to video.

Perhaps it should be mentioned that these must only be used with 
compatible codecs. This is hinted at in section 7.2.2, but isn't very 
explicit.

It might also be good to mention that parameters meaningful for 
non-video codecs may be defined in the future.

In addition to the parameters listed here, there is another ('depend') 
that is mentioned in a few places. The closest thing to a real 
definition of the semantics of if are in section 10.3. I think there 
ought to be an explicit definition of it here - or at least a mention 
with a cross reference to the section where it is defined.

* Section 7.2.2:

Bullet 2 requires that any pt mentioned in a=rid must also be mentioned 
in an a=rtpmap or a=fmtp attribute. Did you intend to exclude the use of 
default PTs - that generally work without rtpmap or fmtp? Wouldn't it be 
better here to simply require that the PT in the rid line also be 
mentioned in the m-line? (I realize that default PTs are only for audio, 
and there is currently no need for rid with audio, but that might not 
always be the case.)

* Section 7.3:

Each rid line in the offer has a direction of send or recv. Presumably 
that is from the perspective of the sender of the sdp. I would expect 
(and the examples show) that in the answer each send would be changed to 
recv and visa versa. But this isn't mentioned.

In the case of errors, the rule is to omit the rid line for the rid in 
the answer. The effect of this is to process the media stream as if 
there were no rid constraints. It might be good to mention that if the 
answerer doesn't want to handle the media stream, or the specific PTs 
involved, without any rid constraints, then it should reject the m-line, 
or omit the affected PTs from the m-line in the answer.

rid-fmt allows the general 'fmt' syntax from 4566. That allows 
non-numeric values for non-rtp transports, but requires numeric PT 
values for RTP. Since rid applies only to RTP, the syntax here could be 
restricted to numeric PT formats.

* Section 9:

This doesn't quite conform to the pattern introduced in rfc4566bis. (It 
is not good to include "a=" in the syntax definition for individual 
attributes.) I suggest replacing the rid-syntax line with:

   rid-value = rid-identifier SP rid-dir SP rid-fmt-list SP rid-attr-list

(And also see my comment on section 12.2.)

The syntax of rid-identifier permits '-----', '-_" and other similar 
non-human-friendly identifiers. It might be good to limit this (for 
readability). E.g.

   rid-identifier = 1*alpha-numeric *(("-" / "_") 1*alpha-numeric)

The 'pt=' is entirely redundant. (The rid-fmt-list can be identified 
positionally.) Why is it there?

There seems to be some ambivalence in the text whether you are defining 
rid *attributes* or rid *parameters. In section 6 they are called 
parameters. Here there is a rid-attr-list but the elements of the list 
are called rid-xxx-param. Can you please decide on one term for these 
that stick to it?

* Section 10.*:

The a=rid lines in most/all of the examples are inconsistent with the 
syntax. E.g. The following:

    a=rid:1 send pt=*; max-width=1280; max-height=720; max-fps=30

ought to be:

    a=rid:1 send pt=* max-width=1280;max-height=720;max-fps=30

* Section 10.1:

This example shows that the proposed mechanism isn't ideal for this 
case. There are a *lot* of duplicated sdp lines devoted to specifying 
the identical attributes for multiple rid values. It seems like there 
ought to be syntax to avoid that redundancy.

* Section 12.2:

This doesn't quite conform the the pattern introduced in rfc4566bis.

I suggest the following:

    This document defines "rid" as SDP media-level attribute. The
    "rid" attribute is used to identify characteristics of RTP stream
    with in a RTP Session.

    Name: rid

    Value: rid-value

    Usage Level: media

    Charset Dependent: possibly

       This attribute is generally not charset dependent.
       However individual rid-level-attributes may be defined
       to be charset dependent.

    Syntax:

          See section 9.

    Example:

          a=rid:1 send pt=* max-width=1280;max-height=720;max-fps=30

* Section 12.3:

I'm still unclear of the relationship between rid-level attributes and 
other (session/media) attributes. Those others, regardless of the levels 
they apply to, belong to a single namespace. Do rid attributes occupy 
another level within the same namespace, or do they define a new namespace?

If they occupy a new namespace, it would be valid to define a rid-level 
attribute with the same name as (for example) a media-level attribute. 
That would be very confusing.

	Thanks,
	Paul

On 10/2/15 6:48 PM, Suhas Nandakumar wrote:
> Hello All
>
>     As indicated by Adam in his email , we have submitted the draft
> defining "RID".
>
>     The draft can be found here:
> https://datatracker.ietf.org/doc/draft-pthatcher-mmusic-rid/?include_text=1
>
>     Please provide your feedback on the same.
>
> Thanks
> Suhas