Replying to just one part On Jul 19, 2011, at 2:27 AM, Miguel A. Garcia wrote:
>>> - Section 4.2 reads: >>> >>> To remain backwards compatible with conventional SDP usage, >>> the format field of the m-line MUST have the arbitrarily-selected >>> value of "1". >>> >>> The comment is that in other protocols, for example, MSRP [RFC4975] it >>> has been selected to use an asterisk "*" in the format field. I wonder if >>> it is possible to unify criteria, in order to allow usage of conventional >>> SDP parsers. >> >> I don't see how this has any relationship to "conventional SDP parsers". >> Any SDP parser should be able to parse the value "1", and the allowed >> value is protocol-specific anyway. Since the values of the media and >> protocol fields are completely different in our case, and because this >> would break existing implementations of MRCP, I see no sufficient reason >> to change the value. > > Let me give you an example. If I have an SDP class that encodes SDP, the > class would not be able to decide whether to write an asterisk "*" or a "1" > in the format field, when you invoke it. Writing "1" or "*" will be dependent > on the application. > > Then, if you see an SDP body captured by Wireshark or similar, you will need > to know which application generated it before you could decided whether the > SDP is correct or not. And Wireshark will not be able indicate "format is > irrelevant" until it knows which application carried that SDP. > > I haven't heard a good reason for keeping the value "1". So, I am still > proposing to reuse the "*". Miguel - your SDP class will have to ask the application what the <fmt> field means for a given <proto> field value _anyhow_ to populate it correctly. Similarly, something like wireshark will have to recognize what is in the <proto> field to do any higher level of verification beyond the basic syntax in 4566 (which is to match a token as 4566 defines token, and either * or 1 will match). As Dan points out already there is deployed code that this change would break, and I don't see the benefit you are arguing for. RjS _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
