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

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 27 Jan 2006 09:20:04 -0500

> The advantage to using Data over Tel is that Data exists and 
> requires no extensions to handle this case. To use Tel for 
> this, it must be extended with a new cnam parameter that is 
> not useful in any other context and in fact will probably add 
> confusion around the use of Tel in other contexts.
>
> Note that I am not attached to Data, but it just seemed to be 
> an existing URI that was sufficient for the purpose.

Since the URI is the sub-type of an Enumservice, perhaps we can progress
with two subtypes, one as data: and one as tel:.  We may also discover
some others of interest based on discussion in Dallas as folks consider
how (and if) they may use it in practice some day.

Jason

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jan 2006 10:43:09 -0500

Jason,

My point about using data is that, if you do so, you do not need to 
extend tel with the cnam parameter. I prefer not to extend tel 
unnecessarily, since each added parameter then must be considered by all 
that use the tel uri. I don't think this particular parameter would have 
applicability except when tel is used as the output of enum for this 
particular use of enum.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jan 2006 13:08:25 -0500

Richard Shockey wrote:
> Paul Kyzivat wrote:
>> unnecessarily, since each added parameter then must be considered by 
>> all that use the tel uri.
> 
> 
> Well then I'm assuming you dont really support
> 
> http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-00.txt
> Why have a registry if you want to severely restrict parameters 
> associated with a tel URI?

I'm ok with that. I believe in extensibility, and registries facilitate 
that.

But the existence of a registry doesn't obviate the need to carefully 
consider what extensions one makes.

>  I don't think this particular parameter would have
> 
> Point taken but .. it is pretty obvious that CNAM is directly related to 
> a PSTN phone number and as such could/should part of the tel URI which 
> is our argument

That is an argument that it *is* applicable more widely.

I think it is a fair subject to discuss. But it then should be portrayed 
that way, and all the implcations of using it considered.

My main problem with it is that calling name is a meaningful datum 
regardless of what sort of URI describes the address of the caller. 
Embedding the calling name in TEL would result in one of a few outcomes:

- a requirement to embed calling name in other URI forms - at least SIP. 
(ugh)

- using some other scheme to convey the calling name in sip requests, 
and ignoring the use of cnam in TEL for this purpose. (eliminates 
general requirement to carry calling name in TEL.)

- using the cnam in TEL when the calling address is a TEL, and using a 
different (non URI-based) method to convey the calling name when TEL is 
not used. (ugh)

We already have enough of a problem with too many ways to represent 
caller identity (including name) in SIP. We don't need more ways that 
only work in limited contexts.

> Another argument is that I'm not sure many proxy SS vendors know how to 
> deal with data: but the can parse tel: uri's and associated parameters 
> which is the flip side of your concern.

This whole use of enum for calling name is *new* and will require some 
special development. In the overall context of things, doing this 
parsing is trivial. Shouldn't be any harder than parsing a new cnam 
parameter in TEL.

> Either option clearly gets the job done, I'm just not fully convinced a 
> cnam parameter extension harms the usefulness of the tel: URI and when 
> its clear that we need a registry of tel: parameters because it is 
> anticipated there may be N of them.

It would be one thing if the parameter was already defined for some 
other purpose. But I just don't buy adding an *extension* to tel for the 
sole purpose of using tel to *tunnel* information. In the proposed 
application the rest of the tel URI isn't used at all is it?

	Paul

>>>> requires no extensions to handle this case. To use Tel for this, it 
>>>> must be extended with a new cnam parameter that is not useful in any 
>>>> other context and in fact will probably add confusion around the use 
>>>> of Tel in other contexts.
>>>>
>>>> Note that I am not attached to Data, but it just seemed to be an 
>>>> existing URI that was sufficient for the purpose.
>>>
>>>
>>>

---

From: Richard Shockey <[email-masked]>
Date: Sat, 28 Jan 2006 15:07:16 -0500

> consider what extensions one makes.

Of course ...

>> Point taken but .. it is pretty obvious that CNAM is directly related 
>> to a PSTN phone number and as such could/should part of the tel URI 
>> which is our argument
> 

OK this is what I was hoping to hear as we've said before the authors of 
this draft have  no "moral objection" to the use of data: however I 
wanted to make sure there was a rational technical argument for not 
using tel.

I just want to see where rough consensus is. This is clearly a warm 
discussion topic for Dallas and its useful to flush out the arguments in 
advance and Paul I thank you for that.

> 
>> Another argument is that I'm not sure many proxy SS vendors know how 
>> to deal with data: but the can parse tel: uri's and associated 
>> parameters which is the flip side of your concern.
> 

Well could you check with some folks on Bowers Ave or Richardson TX on 
that first. :-) Every time I heard some vendor whining on what it would 
take to actually implement 3761 I kept hearing 18-24 months etc. In fact 
  we put the two parameters tel and sip in the PSTN LNP draft 
specifically because we were aware some vendors ( who shall remain 
nameless) were unable to process a tel: URI.

> 
>> Either option clearly gets the job done, I'm just not fully convinced 
>> a cnam parameter extension harms the usefulness of the tel: URI and 
>> when its clear that we need a registry of tel: parameters because it 
>> is anticipated there may be N of them.
> 

A. I'm not sure. Its a highly specialized form of query response that in 
the PSTN does not occur at call origination only after call setup has 
begun. Now if the "well known" databases were structured differently and 
contained multiple parameters then I could see cnam parameter combined 
with others and then it would be logical to combine in a single tel.

>>>>> must be extended with a new cnam parameter that is not useful in 
>>>>> any other context and in fact will probably add confusion around 
>>>>> the use of Tel in other contexts.
>>>>>

-- 

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