I'll note that RFC 2396 has been obsoleted by RFC 3986. It
seems to
give a somewhat clearer explanation of what needs to be
escape and
what doesn't.
"Section 2, on characters, has been rewritten to
explain what
characters are reserved, when they are reserved, and why
they are
reserved, even when they are not used as delimiters by
the generic
syntax."
The basic rule is
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting
data
must be
percent-encoded before the URI is formed.
The relevant general rule is
URI producing applications should percent-encode data
octets that
correspond to characters in the reserved set unless
these characters
are specifically allowed by the URI scheme to represent
data in that
component. If a reserved character is found in a URI
component and
no delimiting role is known for that character, then it
must be
interpreted as representing the data octet corresponding
to that
character's encoding in US-ASCII.
In my view, this means, roughly, that if a particular URI
doesn't
need one of the delimiters (reserved) characters as
delimiters and
there is no ambiguity, it doesn't have to be %-encoded,
although it
is obviously always safe to do so.
In RFC 3986, # is a gen-delims and * is a sub-delims.
However, in a SIP URI, neither # nor * have any special
function.
Thus, it would, in principle be safe to not escape them. RFC
3261
seems pretty clear, however, on the fact that
telephone-subscriber
must follow the rules for 'user' components, where neither #
or * is
allowed.
userinfo = ( user / telephone-subscriber ) [
":" password ] " "
user = 1*( unreserved / escaped /
user-unreserved )
user-unreserved = "&" / "=" /
"+" / "$" / "," /
";" / "?" / "/"
Thus, I think there are two choices:
- Just escape them. Not as pretty, but most of the time,
these URLs
are not visible to humans, so it doesn't seem to be a big
deal.
- The draft would have to update RFC 3261 and explicitly
change
several pieces of the userinfo discussion in RFC 3261,
allowing those
characters in userinfo as additional user-unreserved
characters.
In general, the escaping notation of URLs is very confusing,
as the
BNF often shows the pre-escaping character set, at least in
some
older RFCs.
On Mar 6, 2007, at 4:02 PM, Paul Kyzivat wrote:
>
>
> Juha Heinanen wrote:
>> Paul Kyzivat writes:
>> > The proposal would require a revision to the
definition of SIP-
>> URI that > would make it incompatible with RFC
2396. and so
>> what? compatibility cannot be a religious issue if
there are no
>> technical issues and no-one has not pointed out
any.
>
> This organization is in the standards business. So we
at least
> shouldn't be in the business of violating the ones we
have set for
> ourselves. Standards are only useful if they are
followed.
>
> Specifically, from the beginning sip has asserted that
the SIP-URI
> is a URI as defined in RFC 2396. If it isn't, we
shouldn't be
> calling it a URI at all.
>
> SIP URIs can be passed around, stored, and manipulated
as generic
> 2396 URIs by pieces of software that aren't aware of
the specifics
> of SIP URIs. Such pieces of software may well look to
2329 as a
> definition of what to expect, and may fail if given a
"uri" that
> doesn't comply.
>
> Unless you can enumerate all possible (current and
future) uses of
> sip URIs I don't see how you can say there are no
technical issues.
>
_______________________________________________
Iptel mailing list
Iptelietf.org
https://
www1.ietf.org/mailman/listinfo/iptel
|
