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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Jul 2002 17:04:19 +0200

Hi,

I have some comments about the draft.

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>.

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.

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.

Appendix A.

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

The definition from draft-ietf-mmusic-sdp-new-10.txt says:
email-safe =          1*(%x01-09/%x0B-0C/%x0E-27/
                         %x2A-3B/%x3D/%x3E-FF)
                      ;any byte except NUL, CR, LF, or the quoting
                      ;characters ()<>

Which includes lots of more charachters than space which is referenced 
in the text in section 2.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 08 Jul 2002 17:36:02 -0700

Magnus,

Thanks for the feedback.

>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?

>changed. A possible value would be 34 that are a static payload type for 

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.