Hello: I am not sure that this alone will fix the problem in totality. If I were to use the reverse analogy i.e. what if a UA that conforms to this specification offers the request to a "aggressive parsing" UA that is only compliant with RFC 3261? If we are not planning on changing the BNF, I am wondering if this draft should simply say that the string after the "@" sign MUST NOT include a domain name, host address, MAC....? Or if this is ambiguous, simply say that the UA MUST generate *another* cryptographic identifier to be placed after the @ sign?
Thanks, Venkatesh On Wed, Mar 25, 2009 at 1:51 PM, Jonathan Rosenberg <[email protected]>wrote: > I didnt get a chance to say this at the mike. > > You *cannot* change the BNF for the call-id. If you did, you might end up > with the following problem: > > A new UA gets built, compliant to this update. It is one of these > 'aggressive parsing' UAs. It rejects any message which is not compliant to > the BNF. An older, normal RFC-3261 compliant UA sends a call-id which > includes the @-sign. > > According to the BNF of this updated 3261, and based on the strictness of > this aggressive-parsing UAs, it rejects that request as non-compliant. > > As such, you need to keep the BNF, but change the normative language such > that an endpoint MUST NOT include the [@ host] but MUST be prepared to > receive it. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South > Cisco Fellow Iselin, NJ 08830 > Cisco, Voice Technology Group > [email protected] > http://www.jdrosen.net PHONE: (408) 902-3084 > http://www.cisco.com > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip >
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
