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

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

> I'm certainly aware of many of the LDAP products out there 
> for Name Databases. I think the consensus concept inherent in 
> this draft was that since proxy's, SS, CMS's etc will now all 
> have extensive 3271 and DNS support why not use the existing 
> query response mechanism already available to access the Name 
> databases. Adding a LDAP stack _may_ add excessive overhead.

I'd say definitely in my experience.  Some of the softswitch & proxy
guys we've used prefer to keep in in ENUM/DNS as adding LDAP could take
a lot of development time and $.
 
> In any event the two methods can easily co-exist. The market 
> will decide which protocol to use to access the databases.

I think that's essentially the bottom line.  It is about several
technical alternatives and let the market decide which one hunts.

Jason

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

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 27 Jan 2006 21:27:26 +0100

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

I always thought the CNAM is there because there is no other way
to transport this in call setup

I thought CNAM is the Display Name, so I do not see
the problem with SIP here.
 
Or do I misunderstand something here?
 
Richard

________________________________

Von: [email-masked] im Auftrag von Paul Kyzivat
Gesendet: Fr 27.01.2006 19:08
An: Richard Shockey
Cc: [email-masked]; McCandless, Kevin; Livingood, Jason; [email-masked]
Betreff: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt

Richard Shockey wrote:
> Paul Kyzivat wrote:
>
>> 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.
>
>
> 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
>
>> applicability except when tel is used as the output of enum for this
>> particular use of enum.
>
> 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

>>     Paul
>>
>> Livingood, Jason wrote:
>>
>>> 
>>>
>>>> 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
>>>
>>
>
>