Re: [MMUSIC] Review Request - draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC3407 Related)

[Flemming Andreasen <[e-mail]>]

Section 5.20 (RFC 3407), refers to the following attributes with their 
category shown in brackets (note: changed "csdc" to "cdsc"):

a=sqn (NORMAL)
a=cdsc (TBD)
a=cpar (TBD)
a=cparmin (TBD)
a=cparmax (TBD)

I agree with the "sqn" category of NORMAL.

For the rest of them, the challenge we have is that they are essentially 
what we could call "encapsulating" attributes, i.e. they simply encode 
attributes or other parameters. This leads to a problem that may apply 
to other attributes as well: Currently, the mux mechanism seeems to only 
distinguish attributes at the attribute name level, however there are 
attributes where you have the same attribute-name appear many times, but 
further parameters in the attribute distinguish these (and as per the 
above, this distinction may in turn lead to different categories). Also 
note, that these attributes to not actually negotiate use of their 
encapsulated values; a separate signaling mechanism, e.g. O/A exchange,  
would be needed for this (as noted in RFC 3407, Section 2).

For "cdsc", I'd be inclined to put it in category "NORMAL", but for the 
rest of them, I'm not sure any of the current categories match, since it 
really depends on what was encapsulated in them (note that both bandwith 
and attributes can be encapsulated in them).

Thanks

-- Flemming


On 4/26/13 5:24 PM, Suhas Nandakumar wrote:
> Hello Flemming
> This is a request for reviewing the following sections
> 5.20
>
> of the draft
> draft-nandakumar-mmusic-sdp-mux-attributes-02
>
> It will be greatly appreciated if you could inform on your willingness 
> for reviewing the aforementioned sessions.
>
> It would be great to have your review feedback/comments/inputs before 
> June 9th 2013.
>
> The document is available here:
> http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02
>
>
> Thanks in Advance
>
> Regards
> Suhas Nandakumar