Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-srcfilter-01.txt

[Ross Finlayson <finlayson@live.com>]

Magnus,

Thanks for the feedback.

>Section 2 and Appendix A.
>The definition of the filter attribute. Wouldn't it be better to define a 
>short attribute name to the source filter instead of having two attributes 
>called incl and excl? I would propose a=SF:<filter-mode>:<filter-spec>.

I'm not sure.  The syntax of "a=incl:" and "a=excl:" seems more consistent 
with that of other SDP attributes.  OTOH, they introduce two new attributes 
rather than one.  A possible alternative might be something like
         a=filter <filter-mode> <filter-spec>
where <filter-mode> is "incl" or "excl" (or "include" or "exclude").

Does anyone else have an opinion on this?


>Section 2.2.
>The media description 1 port number is not even, Please change to 54320 
>which is a possible number. Also the payload type for video shoul be 
>changed. A possible value would be 34 that are a static payload type for 
>h.263 video.

You're right - thanks for noting this.


>Section 2.2.4
>The example text is in contradiction with the processing rules in section 
>2.1. According to the processing rules all three src adresses (1.1.1.1, 
>2.2.2.2 and 3.3.3.3) are valid for any of the three multicast adresses.

Question for Bob (Quinn): Section 2.1 says
         "all unicast addresses in the <src-list> are valid sources for any
         of the multicast addresses in the address series implied by the
         <number of addresses>."
but the example in 2.2.4 contradicts this.  Which semantics did you intend?


>Appendix A.
>
>The definition of src-list i believe is in error. The addresses should not 
>be seperate by email-safe but rather SP.

Yes, I think so.

         Ross.


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic