[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Summary (Was: [Re: Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986])
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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Paul
> Kyzivat
> 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 "first
> matching 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip