Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2008 17:08:52 -0500

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?

>    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".

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.

>    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.

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.

	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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 15 Feb 2008 15:12:37 -0800

I agree and have an additional question:

What happens if the phone number is actually owned by the end user due
to number portability? It seems in this case a database service is the
essential ingredient.

This is an excellent I-D and I suggest we use it to clear up all these
issues.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Friday, February 15, 2008 4:09 PM
To: SIP IETF; Elwell, John
Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt

John,

>    submitting a request targeted at that E.164 number. 

I'm not convinced about the above. It depends on what you mean by
"should".

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.

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.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Feb 2008 07:36:27 +0000

Paul,

Thanks for reading and commenting on this draft. See below.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 15 February 2008 22:09
> Subject: Re: draft-elwell-sip-e164-problem-statement-00.txt
> 
> John,
> 
[JRE] Yes

> I'm not convinced about the above. It depends on what you 
[JRE] Perhaps I should have phrased it as "one might expect".

> 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.

> present, but otherwise not.
[JRE] That was my intention - with user=phone.

> 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.