Re: Summary (Was: [Re: Question regarding conflicting grammar for IPV6 SIP URI andRFC 3986])

URI's would be the domain of APPS, I would think. Introducing the Apps  
AD's to the conversation.

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 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

_______________________________________________
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