I did not notice it before, but it does make sense. What does seem odd to me
is that apparently a password is allowed (and included in the comparison of
AORs), so johndoe:[EMAIL PROTECTED] and johndoe:[EMAIL PROTECTED] are treated as two
identities
The way a registrar should handle this is stated in section 19.1.1:
"Elements processing URIs SHOULD ignore any disallowed components if they
are present."
According to Section 10.3:
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps. The URI
MUST then be converted to a canonical form. To do that, all
URI parameters MUST be removed (including the user-param), and
any escaped characters MUST be converted to their unescaped
form. The result serves as an index into the list of bindings.This
text could be clarified by stating that the canonicalization should also
remove any URI elements that are not allowed in To header URIs, ref 19.1.2.
This includes the port, but also any headers present
I think the best way to deal with this, is to construct a new URI based on
unescape( to.username [ ':' to.password, if present ] @ to.host )
Regards,
jeroen
----- Original Message -----
From: "Brett Tate" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 03, 2005 4:35 PM
Subject: RE: [Sip-implementors] Question about : and port
numberfollowingSIPTOand SIP From addresses
> URIs in To and From headers are not allowed
> to contain a port number.
That looks like a typo to me! They're the only
URIs not allowed to contain a port number, and
the grammar of section 25 allows port numbers.
It isn't a typo; it was intentionally removed. Since the modification is
not backwards compatible with RFC2543, I don't recommend it trigging a 400
response.
If I recall correctly, the reason for the removal was that the port was
not
considered to be part of the user/device identity.
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
