Paul, Thanks for reading and commenting on this draft. See below.
John > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 15 February 2008 22:09 > To: SIP IETF; Elwell, John > Subject: Re: draft-elwell-sip-e164-problem-statement-00.txt > > John, > > Thanks for opening this can of worms. It is a very important > problem to > solve. > > Did you intend for this to be discussed on the SIP WG mailing list? [JRE] Yes > > > When a UA receives an E.164 number represented as a SIP > URI in a From > > header field, what does this say about the source of the > request? Of > > course, it should indicate that the request originated > at a user who > > has a right to use that E.164 number and who can be reached by > > submitting a request targeted at that E.164 number. > > I'm not convinced about the above. It depends on what you > mean by "should". [JRE] Perhaps I should have phrased it as "one might expect". > > The existing rules for use of SIP URIs don't require that the user be > reachable from the PSTN, or that the user have any > relationship to the > pstn number. The user part is still wholly the responsibility > of the domain. > > A corollary is that there are significant issues about how > the recipient > displays the identity of the caller. If the identity is > displayed based > solely on the e.164 number, without the domain, then it is a > misrepresentation precisely because reverse routing using the e.164 > number may well not reach the same place. > > > However, the last > > of these issues is a far more serious problem: the user > expects a > > communication partner to be from a particular domain (the E.164 > > number is not necessarily an important factor). Seeing > that domain > > in the From: URI, coupled with authentication by means of the > > Identity header field, would satisfy the user's > expectation. Seeing > > a different domain, that of an intermediate service > provider, which > > may or may not be known to the user, would not satisfy the user's > > expectation. The user might not be prepared to accept > the unexpected > > URI and might decide not to proceed with the communication. > > This argument isn't very compelling to me. Nobody using the > PSTN expects > to see the enterprise name as part of the calling "number". > PSTN caller > id with calling name might be relevant, but it isn't a domain name. > > If you want to use sip domain names for authorization > purposes, then it > makes more sense to use *real* sip URIs. [JRE] Yes, but E.164 numbers are used extensively, and a big advantage is that they can be reached from PSTN as well as being reachable from within the SIP world. So it would make sense to be able to use E.164 numbers but also be able to draw the same conclusions about domain as one can for "real" SIP URIs. > > > REQ2: When a UAS receives a SIP request that includes a > SIP or SIPS > > URI identifying the originating user, if that URI contains an > > E.164 number that number alone, when placed in a TEL > URI, must be > > suitable for routing a request back to the originating user. > > Your examples all include ;user=phone, but none of the text says that > you mean that when talking about sip URIs that contain E.164 > numbers. I > am somewhat inclined to agree with this requirement if user=phone is > present, but otherwise not. [JRE] That was my intention - with user=phone. > > IMO, rather than trying to fix up the handling of sip URIs containing > phone numbers we would be better off trying to fix up the use > of TEL URIs. > > The main limitation of TEL URIs is the inability of sip > identity to deal > with them. What we need is a way to extend identity to them in such a > way that it truly proves ownership of the number, in whatever > sense of > ownership we want it to mean. > > I think that can be achieved by translating a TEL URI to its > ENUM dotted > inverted number domain name format, and then applying sip identity to > that. It means that if I am the end user assigned usage of > TEL:+1978-555-1234 then *I* or some middle box acting as my > agent, must > have a certificate for 4.3.2.1.5.5.5.8.7.9.1.e164.ansi. [JRE] This brings us firmly back to the concept of ownership of E.164 numbers, since clearly if a recognised CA is going to sign a certificate for such a domain, that domain would need to demonstrate some kind of ownership. I gather in North America this would fit well with the idea that enterprises "own" their E.164 numbers (I am referring here to a comment from Henry), and if this is true elsewhere it might be a realistic proposition. I do like your suggestion. > > Thanks, > Paul > > > _______________________________________________ Sip mailing list http://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
