Re: [MMUSIC] Reviewing the SCTP SDP draft - draft-ietf-mmusic-sctp-sdp-05

[Paul Kyzivat <[e-mail]>]

Here is the review I promised of draft-ietf-mmusic-sctp-sdp-05.

(This isn't a full WGLC-like review. I focused on things that popped up 
in the diff from the prior version. That gave me enough.)

There are a number of problems in section 5.1:

>       sctpmap-attr        =  "a=sctpmap:" sctpmap-number media-subtypes [streams]

Nit: This line is too long.

>       sctpmap-number      =  1*DIGIT
>       protocol            =  labelstring
>         labelstring         =  text
>         text                =  byte-string
>       streams      =  1*DIGIT

The "media-subtypes" in this draft replaces "protocol" in the prior 
version. But this change is incomplete. The symbol "media-subtypes" is 
not defined, but the old symbol "protocol" is still defined but 
unreferenced.

Just renaming the definition of "protocol" isn't a sufficient fix - that 
definition has its own problems. It is currently ultimately defined as a 
byte-string. This allows almost anything, and so it is incompatible with 
allowing anything else on the line after it. (Such as "[streams]".) A 
more restrictive definition is needed. (E.g., "token".)

I note that "media-subtypes" is plural. Is that intended? Is there a 
desire to allow more than one? There is *no* discussion of 
"media-subtypes" in the document. That also needs to be fixed.

While I understand the intent, IMO the symbol "streams" is not ideal. It 
sounds like something intended to identify specific streams rather than 
a bound on the number of streams. I suggest renaming this to something 
like "max-streams".

A possibility to clean up some of the things above is:

       sctpmap-attr        =  "a=sctpmap:" sctpmap-number
                              media-subtypes [max-streams]
       sctpmap-number      =  1*DIGIT
       media-subtypes      =  token
       max-streams         =  1*DIGIT

My first thought was that "media-subtypes" was intended to specify a 
mime-type, such as is used to define a codec. And the examples using T38 
suggest that. But if that is so, it needs to have both type and subtype 
(e.g., "image/t38"), and that would require a further syntax change. But 
I don't think that works. ISTM that the protocol needs to be defined per 
sctp-stream-id. Defining it for an entire sctp port would mean that all 
the streams would have the same mime-type. That is generally unrealistic.

I think addressing that means defining a new attribute. And that is 
already being addressed by 
draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.

Perhaps "media-subtypes" isn't needed at all.

	Thanks,
	Paul


On 12/16/13 7:59 AM, Ari Keränen wrote:
> Hi Ekr, Paul, and Roni,
>
> Thanks once more for volunteering at the Vancouver meeting to review the
> SCTP SDP draft. We hope to see your reviews soon so that we can move the
> draft forward.
>
> Here's a link to the latest revision:
> http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05
>
>
> Cheers,
> Ari
>