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