WIth my AD hat on ...
If you want to update/discuss/change/abuse 3986, probably the best
place to to that would be on the APPS area list at [email protected]
It would be up to the Apps ADs, but I suspect that change to the BNF
suggested below is too significant a change to be done with an Errata.
Cullen
On Dec 19, 2008, at 1: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
