Subject: [Simple] tel URIs in common policy

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Aug 2005 10:19:37 -0400

In a side conversation, Hannes suggested a solution to the tel URI 
problem we discussed during the WG meeting, akin to what's done in the 
geopriv coordinate system parameter, namely to have a parameter that 
identifies the scheme, as in

<one scheme="tel" id="+1-212-555-1234"/>

or

<one scheme="sip" id="[email-masked]"/>

if you really only want to match SIP identity sip:[email-masked].

The default with no scheme parameter is "matches any user@domain scheme".

In order to complete finishing the section of the spec, I'd value quick 
feedback on the idea.

Henning

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Aug 2005 18:49:08 -0400

I haven't been following common policy closely for awhile, so I may put 
my foot in my mouth here. But anyway...

You have mentioned the desire to ignore the difference between sip and 
sips. This probably makes sense, at least most of the time. (But not 
always - you may only want to grant full access to your presence state, 
with sensitive info, over a sips connection.)

Also, schemes are more than just distinct namespaces. There are 
significant differences from scheme to scheme about how equivalence of 
names is defined. Tel URIs must be compared differently for equivalence 
than sip (user=ip) URIs. Separator characters must be ignored, and 
parameters must be properly compared. (e.g. phone-context).

Just as sip and sips URIs might be considered equivalent for purposes of 
identity equivalence, so may tel and sip/sips;user=phone. It seems many 
people prefer to use sip URIs for phone numbers, using whatever domain 
name is handy for them. This can cause a huge mess in determining 
equivalence. Technically one should not consider to sip URIs with 
different domains to be equivalent even if they both seem to represent 
the same phone number, and it gives me heartburn to suggest doing so, 
but pragmatically I think it must probably be supported. Specifically, I 
think all the following need to be considered equivalent:

	tel:+1-555-987-6543
	tel:+15559876543
	sip:+1(555)[email-masked];user=phone
	sip:[email-masked];user=phone

If we don't get this right, people will end up not being able to set 
policy for callers without understanding how the caller is identified 
from each different device he uses. If you end up needing a call log to 
figure out how your callers are identified before you can authorize 
them, then the system will be nearly unusable.

We also talked last week about wildcarding. I think there will be 
demand/need for this. Things like:

	tel:+1-900-nnn-nnnn

Even this assumes that global form numbers are being used. Various forms 
of dial strings make more of a mess. But lets not discuss that for now.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 09 Aug 2005 19:52:39 -0400

> parameters must be properly compared. (e.g. phone-context).

I don't think there's any disagreement that E.164-style and 
user@host-style URIs are sufficiently different that treating them as 
the same space is not likely to be productive or intuitive.

>     sip:[email-masked];user=phone

This seems like an item for the 'ID management' document to consider.

> them, then the system will be nearly unusable.

I fully agree. This discussion is very much tied to the 'ID management' 
draft discussion. I'm on the "usability" hobby horse these days, but I 
think in general, these equivalences should be as consistent as 
possible. It is very confusing if two identifiers are treated the same 
in one context and then suddenly differ in another - unless there's some 
explicit "loose/strict" flag or other obvious indication.

> of dial strings make more of a mess. But lets not discuss that for now.

How useful is this likely to be, at least for presence and access to geo 
information?

Would we need to support the equivalent for domains, so that

domain="cisco.com"

matches

cisco.com
engineering.cisco.com
host17.engineering.cisco.com

[and other permutations]
?

---

From: Aki Niemi <[email-masked]>
Date: Wed, 10 Aug 2005 12:56:54 +0300

Hi,

I kind of grew fond of the idea Cullen and I came up with in a private 
conversation, namely treating telephone numbers as domains similar to 
when issuing a DNS ENUM query.

In essence, to match +1-232-555-1234, you'd have an identity conditions 
such as:

<many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />

This has an interesting additional property of being able to match based 
on country code, area code, etc. For example, to match all Finnish 
telephone numbers, you'd have:

<many domain="8.5.3.e164.arpa" />

Not being an expert on ENUM or E.164 in general, I suspect this is 
horribly broken, but it pleases the aesthethic eye.

Cheers,
Aki

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 10 Aug 2005 08:03:12 -0400

Aki,

I have a few concerns about this:

- user interface: ENUM-style identifiers are not exactly the most 
user-friendly domain names, given the reversal of digits; I suspect that 
in many cases, applications will generate the rules, but probably not in 
all cases.

- confusion: There's lots of talk about carrier ENUM, using TLDs other 
than e164.arpa. I suspect we'd see "my number is in e164.org, so let me 
use that postfix instead".

- user expectation: it seems that a user would expect the ENUM entry to 
exist if one specifies the domain name; this is not likely to be the case;

- consistency: the presence of a "domain" parameter signals that this 
has 'id' entries with user names in that domain. This clearly makes no 
sense here.

I don't see which problem this would solve compared to the scheme 
parameter proposal. You'd still have to flag the domain as being 
"special", as "sip:[email-masked]" doesn't make a 
whole lot of sense.

Henning

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2005 14:18:38 -0400

Aki,

> <many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />

Then what do you do with sip:[email-masked];user=phone ?

I don't think you can convert it to:

    4.3.2.1.5.5.5.2.3.2.1.foo.com

and if you could then it it wouldn't match the e164.arpa form.

> <many domain="8.5.3.e164.arpa" />

It only does if you declare that a domain matches anything it is the 
tail of. You may sometimes want that, but I don't think you do in general.

	Paul

>> In order to complete finishing the section of the spec, I'd value 
>> quick feedback on the idea.
>>
>> Henning
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 10 Aug 2005 14:46:42 -0400

Paul

Not sure yet what I think of the basic idea, but
   sip:[email-masked];user=phone
should be equivalent to
   tel:+1-232-1234

So I think you CAN convert it to "enum" form.

You might have more problems with
   sip:[email-masked]

That may be equivalent to
   tel:1234;phone-context=foo.com
but you don't know that a priori.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Wednesday, August 10, 2005 2:19 PM
To: Aki Niemi
Cc: [email-masked]; ext Henning Schulzrinne
Subject: Re: [Simple] tel URIs in common policy

Aki,

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Aug 2005 21:13:53 -0400

Henning Schulzrinne wrote:
>> always - you may only want to grant full access to your presence 
>> state, with sensitive info, over a sips connection.)
> 
>> names is defined. Tel URIs must be compared differently for 
>> equivalence than sip (user=ip) URIs. Separator characters must be 
>> ignored, and parameters must be properly compared. (e.g. phone-context).
> 
>> Just as sip and sips URIs might be considered equivalent for purposes 
>> of identity equivalence, so may tel and sip/sips;user=phone. It seems 
>> many people prefer to use sip URIs for phone numbers, using whatever 
>> domain name is handy for them. This can cause a huge mess in 
>> determining equivalence. Technically one should not consider to sip 
>> URIs with different domains to be equivalent even if they both seem to 
>> represent the same phone number, and it gives me heartburn to suggest 
>> doing so, but pragmatically I think it must probably be supported. 
>> Specifically, I think all the following need to be considered equivalent:
>>
>>     tel:+1-555-987-6543
>>     tel:+15559876543

I'm not convinced of that. Especially given the reception in paris, I 
think that doc, if it goes anywhere, will end up being a best practices 
document focused on how managers of domains and applications manage the 
names they assign.

This is something entirely different. It is about matching rules.

>> from each different device he uses. If you end up needing a call log 
>> to figure out how your callers are identified before you can authorize 

They may both be related to usability, but I think they are otherwise 
different efforts.

>> Even this assumes that global form numbers are being used. Various 
>> forms of dial strings make more of a mess. But lets not discuss that 
>> for now.
> 

I guess that particular example may not be a good one, since I doubt I 
would ever receive a request where the caller address was a 900 number.
But other wildcards might make sense:

	tel:+1-978-936-nnnn

would cover all cisco business phones at my site. With a few similar 
numbers I could grant access to most cisco business phones.

> host17.engineering.cisco.com

I think we have to take those on a case by case basis. I don't think it 
generally makes sense to do that. There should be some explicit way to 
do it. E.g. domain="*.cisco.com" or domain="**.cisco.com".

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 12 Aug 2005 20:25:52 +0300

Hi Henning,

> in many cases, applications will generate the rules, but probably not in 

If these rules end up edited by hand by a human being, then I would 
agree. But is that really realistic assumption?

> use that postfix instead".

You are probably right. However, I was proposing that this be merely a 
convention for representing phone numbers; these would actually never be 
used in an actual ENUM query.

> exist if one specifies the domain name; this is not likely to be the case;

I would disassociate the representation of telephone numbers from any 
address resolution, but I am starting to see it may not be that easy.

> has 'id' entries with user names in that domain. This clearly makes no 

Correct, this would mean telephone numbers would be matched only using 
the <many> construct, and never the <one>.

> "special", as "sip:[email-masked]" doesn't make a 

I think the main benefit would be the ability to match based on country 
code for example -- this depending of course whether example.com is 
expected to match *.example.com. I think it should, and I always assumed 
that it does, but Paul didn't think so.

If that is not the case, then the e164.arpa- proposal does not add much.

Cheers,
Aki

>> In essence, to match +1-232-555-1234, you'd have an identity 
>> conditions such as:
>>
>> This has an interesting additional property of being able to match 
>> based on country code, area code, etc. For example, to match all 
>> Finnish telephone numbers, you'd have:
>>

---

From: Aki Niemi <[email-masked]>
Date: Fri, 12 Aug 2005 20:45:46 +0300

Hi Paul,

> and if you could then it it wouldn't match the e164.arpa form.

Well, 'sip:[email-masked];user=phone' is indeed a tricky 
identity to put into a From header in the first place. I'm not sure it 
is a telephone number at all. Why wouldn't the From include a tel URL?

I suppose that matching a SIP URI converted from a tel URL will be a 
problem regardless of the way in which we choose to represent them in 
common policy.

> tail of. You may sometimes want that, but I don't think you do in general.

Can you describe cases where it should not? I had always assumed 
example.com matched any subdomain of example.com as well. All the way 
down to where domain="org" would match all domains under the .org TLD.

Cheers,
Aki

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Aug 2005 15:56:43 -0400

> is a telephone number at all. Why wouldn't the From include a tel URL?

Personally, I generally think it should. However I have run into many 
people who don't seem to believe in tel URIs, and always use the sip 
form. I would like to convince them of the error in their ways, but no 
luck so far.

The other case is when I really, definitely, only want to be contacted 
via SIP.

> problem regardless of the way in which we choose to represent them in 

I am relaxing my theoretical objections in favor of pragmatism, and 
suggesting that for purposes of determining what authorization policy to 
apply it will be ok to treat this as a phone number.

> down to where domain="org" would match all domains under the .org TLD.

Well, suppose there is a domain called cisco.com. NAPTR and SRV entries 
map this to phones.cisco.com - a sip server for corporate addresses at 
Cisco. There may be another domain - test.cisco.com with NAPTR and SRV 
entries mapping to test-phones.cisco.com. Those servers are under 
independent administration.

My decision about whether to authorize users from sip:cisco.com is 
independent of whether to authorize users from sip:test.cisco.com. It is 
especially the case that authorizing sip:[email-masked] and 
sip:[email-masked] needs to be independent.

Now I indeed MAY want to authorize all domains ending in cisco.com. But 
that needs to be a choice that I can make or not as I prefer.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 Aug 2005 20:39:06 -0400

cc'ing geopriv since all of this is about a geopriv document.

I'll reply to some of the technical comments inline, but I want to step 
back a second here.

All of this discussion is making it clear that there is a MUCH bigger 
mess here that needs attention, around phone number usage, 
interpretation and equivalence across tel and SIP URI. This is a common 
source of interop problems in the wild and it makes sense to address it. 
However, the problem at hand is to complete the common policy document, 
and it seems to me a mistake to hold up common policy until that mess is 
sorted out. Furthermore, I would argue that the common policy spec is 
not the place where that mess should be sorted out.

My suggestion therefore is to keep the "id" attribute as an NAI form, 
and make sure common policy is extensible to allow other ways of 
representing identities in the future. We then declare phone numbers out 
of scope for this version of common policy, finish that spec, sort out 
the tel/sip uri mess, and when thats done, we can issue an extension to 
common policy that adds phone number support.

more inline.

> form. I would like to convince them of the error in their ways, but no 

I think the problem is that we've not made it clear what the semantic 
differences really are.

> apply it will be ok to treat this as a phone number.

Stepping back for a sec, I think there are real differences between the 
tel URI and the sip version. The way to think about it is that the tel 
URI is a NAME, and you need to think of it as if it were a URN. A SIP 
URI is an address. Procedures like enum allow the resolution of a name 
to an address.

As such, it really makes no sense to compare a name and an address. Just 
because I work at 600 Lanidex Plaza in Parsippany, does that make 
"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza, 
Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel 
URI and SIP URL are NEVER equivalent; you need to convert the name to an 
address for comparison.

Givne this, the meaning of sip:<phone-number>@domain;user=phone means 
that the domain is asserting ownership of the identity in the user part, 
in this case a global phone number. As such, its appropriate to use this 
form only when it is authoritatively known that the domain in question 
"owns" that phone number.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2005 17:41:11 -0400

Jonathan Rosenberg wrote:

>> suggesting that for purposes of determining what authorization policy 
>> to apply it will be ok to treat this as a phone number.
> 

As far as general comparisons are concerned, I agree with you.
But I don't think matching caller "identity" for purposes of 
authorization need be viewed as a general URI comparison problem.

I don't have a lot of control over the way people identify themselves 
when they call me. Somehow I must recognize their identifications of 
themselves in a way that is sufficient for my needs. If I need to do 
funky huristic comparisons to achieve that, so be it.

It is for this reason that I think we can do special things here. We 
know the identification of the caller will be some form of URI. The ones 
if interest here are sip, sips, tel. The values we put into the policy 
don't need to be URIs - practically speaking they are patterns to be 
matched against caller identification. URIs, using URI comparision are 
one form of pattern match. But we can define something looser - either 
the matching algorithm can be different/looser, and/or the pattern 
itself can be different/looser.

What I am proposing is both: patterns that are a superset of valid URIs, 
and a matching algorithm that is similar to but looser than just pattern 
matching. In particular:

- a pattern containing a tel uri would be matched against sip and sips 
uris with user=phone by simply comparing the user parts using tel 
matching rules.

- perhaps allowing a wildcard character in a "tel" pattern - e.g. an "n" 
instead of a digit. Match by ignoring corresponding character in target.

Of course it wouldn't be necessary to use something that looked like tel 
format to represent this. We could make up some other format that was 
clearly specific to the use at hand. Semantically it wouldn't make any 
difference.

Similarly, I think there is an need for a way to say: match either a sip 
or sips uri. That of course is just syntactic sugar, but I doubt people 
will be happy having to include every target twice, so it is probably 
important.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Aug 2005 20:05:34 -0400

Jonathan Rosenberg wrote:

>>> identity to put into a From header in the first place. I'm not sure 
>>> it is a telephone number at all. Why wouldn't the From include a tel 
>>> URL?
>>

I'd like to think that is the case. But it is so pervasive I suspect 
there are multiple world views, or religions, here.

> "owns" that phone number.

*I* could potentially agree with that, but it seems most people don't.

In general, I think all the above means is that the domain in question 
is accepting responsibility for getting the request wherever it goes. It 
might not own the phone number, in which case it may use peering or a 
pstn gateway to get to the right place.

It seems very popular for a UA to construct such a URI, with the domain 
of its service provider, to ask the service provider to get this to the 
right place.

I think that is entirely wrong, but it seems we have 80% of the world to 
convince of that.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Aug 2005 22:13:55 -0400

I agree with Jonathan that there doesn't seem to be a simple solution to 
the tel problem and that we might want to defer this.

However, we still need some agreement on the domain matching issue 
raised below.

My inclination, based on what I'd users expect to see happen, is to either

- treat domain.com as allowing *.domain.com and assume that the need to 
restrict matching for policy reasons in the manner Paul described is 
sufficiently unlikely;

- adopt a convention that .cisco.com (not leading dot) allows 
*.cisco.com, while cisco.com does not.

I just can't see having a flag or similar mechanism to further 
complicate the matching rules for rather odd corner cases.

Henning

Paul Kyzivat wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2005 00:09:55 -0400

> *.cisco.com, while cisco.com does not.

I would be ok with .cisco.com, or *.cisco.com.
I'd be less happy with not allowing the option.

	Paul

>> Well, suppose there is a domain called cisco.com. NAPTR and SRV 
>> entries map this to phones.cisco.com - a sip server for corporate 
>> addresses at Cisco. There may be another domain - test.cisco.com with 
>> NAPTR and SRV entries mapping to test-phones.cisco.com. Those servers 
>> are under independent administration.
>>
>> independent of whether to authorize users from sip:test.cisco.com. It 
>> is especially the case that authorizing sip:[email-masked] and 
>> Now I indeed MAY want to authorize all domains ending in cisco.com. 
>> But that needs to be a choice that I can make or not as I prefer.
>>
>>     Paul
> 
>