Hi, Some aspects were discussed within the following thread (see summary item 3). However, it can obviously be raised again on sipcore, apps-discuss, or elsewhere.
http://www.ietf.org/mail-archive/web/sip/current/msg26338.html As far as I know, nothing much happened after Cullen's AD post. http://www.ietf.org/mail-archive/web/sip/current/msg26385.html > -----Original Message----- > From: [email protected] [mailto:sip- > [email protected]] On Behalf Of Paul Kyzivat > Sent: Monday, January 12, 2015 10:04 AM > To: [email protected] > Subject: Re: [Sip-implementors] SIP URI syntax vs. generic URI syntax > > This seems like a subject that should be taken up on an ietf list. > sipcore is the likely one, though that is not the place to deal with the > generic uri syntax. > > ISTM that this was a screwup when 3986 was published and didn't address > backward compatibility with sip URIs. > > Thanks, > Paul > > On 1/12/15 9:28 AM, Doug Sauder wrote: > > Brett, thanks for that helpful reference information. > > > > ISTM that RFC 3986 eliminated the idea of an "opaque" part, so that a > > generic URI has the distinct parts scheme, authority, path, query, and > > fragment. An authority always starts with "//", so in the generic > > syntax, a SIP URI has no authority and always has a path. > > > > Before the mailto URI was defined, email addresses were commonly > > written as [email protected]. *IF* the mailto URI had been defined > > as mailto://[email protected], then the SIP URI probably would have > > followed suit with sip://[email protected]. In that case, all > > would be right with the world and generic URI syntax. Too late for > > that now. > > > > Having said that, I think that "?" and "/" should not be included in > > the user component of a SIP URI, in order to at least somewhat > > accommodate RFC 3986. > > The "?" character delimits the query part, so it should be escaped if > > it is not used as that delimiter. The "/" could be a problem if it > > appears as in sip://[email protected]. When "//" appears at the > > beginning, the generic parser interprets it as an authority instead of > > a path. If "/" is not allowed in the user component, then the > > interpretation of a generic parser would be consistent for every SIP > > URI. > > > > I was not aware of the problem with syntax for IPv6 (discussed in the > > thread you referred to). That's a problem that I think requires > > changes to RFC 3986. > > > > BTW, as another bit of information on this topic, RFC 6068 (Mailto > > URI) has this to say: > > > > 1. A number of characters that can appear in <addr-spec> MUST be > > percent-encoded. These are the characters that cannot appear in > > a URI according to [STD66] as well as "%" (because it is used for > > percent-encoding) and all the characters in gen-delims except "@" > > and ":" (i.e., "/", "?", "#", "[", and "]"). Of the characters > > in sub-delims, at least the following also have to be percent- > > encoded: "&", ";", and "=". Care has to be taken both when > > encoding as well as when decoding to make sure these operations > > are applied only once. > > > > So perhaps a good SIP implementation should use percent encoding for > > "?" and for "//" when it appears at the beginning of a user component. > > > > -- > > Doug Sauder > > > > On 2015-01-12, 7:18, Brett Tate wrote: > >> Hi, > >> > >> And for completeness, RFC 2396 section 3 indicates the following. > >> > >> "URI that do not make use of the slash "/" character for separating > >> hierarchical components are considered opaque by the generic URI > >> parser." > >> > >> I mention it since some attempt to fit the sip-uri as a hier_part. > >> > >> absoluteURI = scheme ":" ( hier_part | opaque_part ) > >> opaque_part = uric_no_slash *uric > >> > >> > >>> -----Original Message----- > >>> From: Brett Tate [mailto:[email protected]] > >>> Sent: Friday, January 09, 2015 4:10 PM > >>> To: 'Doug Sauder'; 'sip-implementors' > >>> Subject: RE: [Sip-implementors] SIP URI syntax vs. generic URI > >>> syntax > >>> > >>> Hi Doug, > >>> > >>> If I recall correctly, the conclusion of the following thread was > >>> that > >> nobody > >>> cares about fixing any of the existing incompatibilities. > >>> > >>> http://www.ietf.org/mail-archive/web/sip/current/msg26318.html > >>> > >>> The following email shows why it might be valid (i.e. structured > >>> subset > >> of > >>> opaque_part of RFC 2396 absoluteURI). > >>> > >>> http://www.ietf.org/mail-archive/web/sip/current/msg26325.html > >>> > >>> The following RFC 2396 section 3.1 snippet may be of interest. > >>> > >>> "The URI syntax consists of a sequence of components separated by > >> reserved > >>> characters, with the first component defining the semantics for the > >> remainder > >>> of the URI string." > >>> > >>> > >>>> -----Original Message----- > >>>> From: [email protected] [mailto:sip- > >>>> [email protected]] On Behalf Of Doug > >>>> Sauder > >>>> Sent: Friday, January 09, 2015 2:51 PM > >>>> To: sip-implementors > >>>> Subject: [Sip-implementors] SIP URI syntax vs. generic URI syntax > >>>> > >>>> The SIP URI syntax in RFC 3261 is not compatible with the generic > >>>> URI syntax in RFC 3986. Specifically, the character "?" should not > >>>> appear in the user component. Arguably, the character "/" > >>>> also should not appear in the user component. > >>>> > >>>> Surely this topic must have been discussed before now. Does anyone > >>>> have information about prior discussions, or other comments on this > >>>> topic? Has there been a previous attempt to make the SIP URI syntax > >>>> compatible with the generic URI syntax? > >>>> > >>>> Thanks! > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
