Re: [MMUSIC] Review of draft-ietf-mmusic-sdp-media-capabilities-13

[Flemming Andreasen <[e-mail]>]

Hi Christer

Thank you for the review comments - feedback below


On 4/30/12 8:27 AM, Christer Holmberg wrote:
>
> Hi,
>
> Eventhough a very detailed mechanism, in the same way as Cullen I 
> could not come up with cases where the mechanism would not work.
>
> I also took a detailed look at the ABNF, where I have some comments.
>
> -----------------
>
> General:
>
> SDP normally has a rather strict syntax. For example, elements are 
> normally separated explicitly with "SP". However, you use "1*WSP" in 
> most places. Is there a reason for having a more relaxed syntax in 
> media cap?
>
Not really, but I have never understood why a text-based protocol should 
choke on white-space. There is a well-defined grammar, so I don't really 
see any reason to change (not least since you'd change to something less 
liberal).

> ----------------
>
>   
> Section 3.3.2.1:
>   
> The section contains examples with a number of rmcap attributes:
>   
>         a=rmcap:1,2 audio G729/8000
>         a=rmcap:1 video H263-1998/90000
>         a=rmcap:2 video H263-2000/90000
>   
> However, I don't think these are valid according to the syntax in section 3.3.1, which does not define the media type ("audio", "video", etc):
>   
>                 a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
>   

Good catch - fixed.
>   
> ---------------
>   
>   
> Section 3.3.8:
>   
> The example contains the following line:
>   
>                 a=rmcap:51 *
>   
> However, I don't think that is valid according to the syntax in section 3.3.1, which mandates both encoding name and clock-rate:
>   
>                 a=rmcap:<media-cap-num-list> <encoding-name>/<clock-rate> [/<encoding-parms>]
>   
>   
> In addition, I find no definition of using "*" for the encoding-name (I assume it is some kind of wildcard).
>   
Outstanding catch :-)

Fixed (to "omcap", which clarifies use of "*" as well)
>   
> ---------------
>   
>   
> Section 4.1:
>   
> See issue on 3.3.8.
>   

Sorry - I don't see the corresponding issue in 4.1. Can you elaborate ?

>   
> ---------------
>   
>   
> a=omcap:
>   
> There is no example showing the a=omcap attribute. I think it would be good to have one.
>   
Expanded example in Section 4.3 to cover omcap.
>   
> ---------------
>   
>   
> a=sescap:
>   
> There is no example showing the usage of optional-configs. I think it would be good to have one.
>   
I changed one of the examples in Section 3.3.8 to illustrate this.

Thanks

-- Flemming


>   
> ---------------
>   
>
> Regards,
>
> Christer
>