On Dec 19, 2008, at 3:04 PM, Hadriel Kaplan wrote:
It's ambiguous with path-rootless, no?But anyway I think the AD's should weigh in on what WG should work on the fix. The fix needs to be applicable to all URIs, and I don't think we have all the right folks to know what the rfc3986 semantics really means generally.-hadriel-----Original Message-----From: [email protected] [mailto:[email protected]] On Behalf Of PaulKyzivat Sent: Friday, December 19, 2008 2:56 PM To: Vijay K. Gurbani Cc: IETF SIP List Subject: Re: [Sip] Summary (Was: [Re: Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986]) Vijay, I agree with the direction - to change 3986.I *think* the proposed syntax sounds right, though I haven't studied the grammar carefully to ensure that it is then unambiguous. (But I think I recall seeing that it is already ambiguous and falls back on the "firstmatching production wins" to resolve that conflict.) Thanks, Paul Vijay K. Gurbani wrote:All: So, to summarize a WG position on this and chart a course forward to close this item, these are the facts: 1) RFC3261 is internally consistent in specifying IPv6 literals (i.e., enclosed in "[" and "]"). 2) RFC3986 is internally consistent in IPv6 literals as well. 3) It was not the intention of rfc3261 to make the SIP URI compatible with rfc2396 URI (rfc3986 came later.) And in fact, if we made the SIP URI compatible with rfc3986, we won't get too far for the reason I pointed out early: Note that rfc3986 defines URI as: URI = scheme ":" hier-part ... heir-part = "//" ... If this was true, a SIP URI would need to be produced as: sip://[2001:db8:10] ... Which, I presume, is not going to happen any time soon (and as Hadriel points out, other URIs (im, pres, etc.) suffer the same fate. Therefore, the only conclusion we can arrive to is that rfc3986 should be modified. If so, then what should the modification be and who should do it? For the "who": Given that rfc3986 did not come out of a WG, there is no mailing list to address this issue on. So, the best we can do is as Hadriel suggested: issue an errata. For the "what", any suggestions? I think Hisham's suggestion is probably the least intrusive one to rfc3986's ABNF while allowing one to generate rfc3261 SIP URIs. To recap: OLD: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty authority = [ userinfo "@" ] host [ ":" port ] NEW: URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty / authority ***** Newly added line ***** authority = [ userinfo "@" ] host [ ":" port ] Does this cause any other problems? Thoughts, comments? If you agree, please say so; that way we can summarize this as the WG position allowing for the next steps to happen (i.e., file errata, etc.) Thanks, - vijay_______________________________________________ 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
