... > Well, yes. If you change the domain part of a URI as it traverses > service providers, you're going to break things. If you mean "what > the user +123456789 means in cisco.com's domain", say > <sip:[EMAIL PROTECTED]>. If you mean "what the user +123456789 > means in siemens.com's domain", say <sip:[EMAIL PROTECTED]>. > And there's no reason to believe that there is any relationship > between the two -- unless you have authoritative information about > *both* domains.
If those URIs included ";user=phone", there is a transitive relationship between the SIP URI and the TEL URI. Without ";user=phone", I agree that no meaning is supposed to be applied to the user-part (the part to the left of the "@"). > If you mean "the E.164 number +123456789", say <tel:+123456789>. > > I don't see anything that will go wrong if people pay attention > to what URIs are defined to mean. > > Now there is a problem with signing tel: URIs, how do you determine > that the signer has the authority to sign a particular tel: URI, but > that's a delegation-of-authority problem that is not inherently > different from other delegation-of-authority problems -- you need a > publicly-known root authority and a tree of delegations. That is one approach to determining who owns something. I have a different approach, which I derived from how we determine if someone owns an IP address when we receive a TCP SYN that is proportedly from that IP address: challange them to prove that packets route the other way. Afterall, the Internet does not have a central authority for who owns an IP address (or else we could secure BGP routing better than we secure it today). In SIP, you accomplish something similar to the TCP SYN cookie by sending a SIP request towards the E.164, asking them to sign the request and return it to you. Details are in draft-wing-sip-e164-rrc-01.txt and comments are welcome. -d _______________________________________________ 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
