Subject: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jan 2006 16:53:46 -0500

Richard,

I understand the rationale for providing cnam as something that can be 
obtained from enum. What I don't understand is the rationale for making 
it a tel uri parameter. Do you expect it to actually appear in a tel uri 
anywhere except the output of this particular enum lookup? I can mostly 
think of reasons why that would be a bad idea.

I am guessing this is just a matter that the enum translations need to 
be URIs, so you needed some URI that could contain the name. And tel was 
one choice close at hand.

It all seems pretty circular, with the entry for the number containing a 
tel uri for the same number, plus the cnam parameter. It also introduces 
an unnecessary bit of overhead because of this redundancy.

Seems like there should be some other URx scheme that would be suitable 
to just contain the name.

	Paul

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

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Jan 2006 17:12:20 -0500

Paul Kyzivat wrote:
> it a tel uri parameter.
  Do you expect it to actually appear in a tel uri
> anywhere except the output of this particular enum lookup?

Probably not.

  I can mostly
> think of reasons why that would be a bad idea.

If you could elaborate on why the use of the tel URI's would be a bad 
idea that would be helpful ..we envisioned using SIP URI's as equally bad.

> one choice close at hand.

It was a practical choice yes.

> to just contain the name.

Ideas?

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Jan 2006 18:12:52 -0500

[Igot bounced from the enum list on the original posting. Will see if 
this works.]

comments inline.

	Paul

Richard Shockey wrote:
>> obtained from enum. What I don't understand is the rationale for 
>> making it a tel uri parameter.
> 

That isn't what I meant. What I meant was that using tel URIs 
*containing a cnam parameter* is a bad idea. For instance, consider the 
following:

	INVITE ...
	From: "George W. Bush" <tel:+12125551234;cnam=jdoe>

and further assume that the enum lookup, according to your proposal, of 
+12125551234 comes back with tel:+12125551234;cnam=janedoe

Then what is the proper calling name to use???

In sip the display name already provides a, uri scheme independent, way 
to convey the name. Having a way to convey the name *in* certain kinds 
of URIs just makes things complicated.

>> be URIs, so you needed some URI that could contain the name. And tel 
>> was one choice close at hand.
> 
>> It all seems pretty circular, with the entry for the number containing 
>> a tel uri for the same number, plus the cnam parameter. It also 
>> introduces an unnecessary bit of overhead because of this redundancy.
>>
>> Seems like there should be some other URx scheme that would be 
>> suitable to just contain the name.
> 
> Ideas?

Taking a quick scan of the IANA scheme registry, I came up with data: as in:

	data:,George%20W%20Bush

That seems to do the job.

---

From: Richard Shockey <[email-masked]>
Date: Fri, 13 Jan 2006 21:00:34 -0500

> [Igot bounced from the enum list on the original posting. Will see if 

It did.

> Then what is the proper calling name to use???

IMHO that which service provider policy determines to be the most 
authoritative which means IMHO the ENUM CNAM query aka janedoe in your case.

That obviously does not mean that a proxy can then rewrite the From 
field data only that it is not authoritative for CNAM display purposes.

Out thinking in the next version of this draft is that only RFC 3325 
P-Asserted Identity can be authoritative for Display Name transport 
within SIP headers.

> of URIs just makes things complicated.

Yes but there is a substantial back channel argument that you need to 
convey display name policy in a response in some manner.

As some of my distinguished colleagues from Verisign Msr Kevin 
McCandless and Manjul Maharishi have pointed out to me....

The PSTN defines several values for CNAM data in the event that there 
are restrictions or that the data is unavaiable. These are defined as 
"Reason for Absence of Name" [R3-50] in GR-1188

Consequently the following responses to a query from a well known 
database may need to be reserved.

Cnam=p  for “Private” defined as the Calling Party does not wish to have 
their Display Name displayed.

Cnam=o for “not available/unaviable” defined as the well known database 
has no data available for that particular E.164 number

> 
>>> I am guessing this is just a matter that the enum translations need 
>>> to be URIs, so you needed some URI that could contain the name. And 
>>> tel was one choice close at hand.
>>
>>> It all seems pretty circular, with the entry for the number 
>>> containing a tel uri for the same number, plus the cnam parameter. It 
>>> also introduces an unnecessary bit of overhead because of this 
>>> redundancy.
>>>

Yuck ..

Well Ok you could say E2U+cnam:data

data:,George%20W%20Bush

or

data:,p

for privacy values .. right ?

I'm not dismissing the idea out of hand.

Lets make it clear your belief is that the fundamental concept of using 
a 3761 Query to find CNAM data is sound. Your only issue is with what is 
the appropriate URI returned. Correct?

If the issue is what is the URI vehicle then .... ..again why would tel: 
be so bad?

Inquiring minds.

--