Re: 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: [email protected] [mailto:[email protected]] 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 [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