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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 14 Jan 2006 00:29:38 +0100

>Ideas?

vcard?

You may then display even more information if the B-terminal supports it

Richard

________________________________

Von: [email-masked] im Auftrag von Richard Shockey
Gesendet: Fr 13.01.2006 23:12
An: Paul Kyzivat
Cc: [email-masked]; [email-masked]
Betreff: Re: [Enum] Re: I-D ACTION:draft-shockey-enum-cnam-00.txt

Paul Kyzivat wrote:
> 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?

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.

> 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 was a practical choice yes.

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

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

--

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

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

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

---

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

> vcard?

Again let me make sure we are on the same page here the issue is NOT 
about using 3761 to find authoritative Display Name Information only 
what is the appropriate URI vehicle to carry that data.

Then to your point the vcard would have to carry within it some policy 
flags as to which elements could be on not be displayed.

> You may then display even more information if the B-terminal supports it

This is interesting since the vcard could also have a URI for html data 
as well.

I've always wanted to see a "display" URI in SIP headers so that when I 
called the pizza parlor on the terminal you could have some cool html 
specials displayed instead of the crappy audio commercial you usually 
get stuck with.

Well in any event this is exactly the kind of discussion I had hoped to 
kick off.

> __

--

---

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

>> You may then display even more information if the B-terminal supports it

On further reflection the issue in your proposal then is how does the 
proxy know what the C/UA is capable of supporting in its display.

Any URI proposed must at minimum support the 15 character ASCII in the 
ANSI specs. The called party's proxy then must be able to parse not only 
the policy of what can and cannot be displayed but also what the CU/A is 
capable of dealing with and not creating too much processing overhead 
for the called parties proxy.

This IMHO was the biggest failure of most ENUM MMS routing schemes. 
Instead of using SIP SDP negotiation first to discover the display 
capabilities of the mobile CUA you sent the MMS object directly to the 
MMSC without knowing if the CUA could even display the object.

This is clearly a vastly more interesting subject than classic Caller 
Display Name.

So the issue at hand is then can a URI object be defined that A. is 
compatible with existing ANSI standards but is extensible enough to 
provide for Rich Display Name capabilities in the future?

--

---

From: lconroy <[email-masked]>
Date: Sat, 14 Jan 2006 21:51:27 +0000

Hi Folks,
  it MUST be me.
How the heck is a proxy supposed to know what display capabilities
a recipient terminal that answers a call has (i.e. at that point)?
Let me guess - yet another complex subscribe/notify/term cap scheme.

Of course, if the caller has an ENUM entry, then problem solved.

CNAM appears to be a mechanism for providing text via some other
means (i.e. not under the control of the calling party).

However, in both cases, why not pass an http: URI to that terminal
(which DOES know its own display capabilities authoritatively) and
leave it at that.

The only policy is whether or not one passes the http: URI to the
destination, or some means for the callee to get that URI.

It may be that what you're really talking about is a gateway, NOT
a proxy - this, however, is not at all clear.

your confusedly (as we trialled a super-CLI with ENUM that in the UK),
   Lawrence

On 14 Jan 2006, at 02:53, Richard Shockey wrote:
> Richard Shockey wrote:
>> Stastny Richard wrote:
>>>> Ideas?
>>>
>>> vcard?
>> Again let me make sure we are on the same page here the issue is  
>> NOT about using 3761 to find authoritative Display Name  
>> Information only what is the appropriate URI vehicle to carry that  
>> data.
>> Then to your point the vcard would have to carry within it some  
>> policy flags as to which elements could be on not be displayed.
>>>
> On further reflection the issue in your proposal then is how does  
> the proxy know what the C/UA is capable of supporting in its display.
>
> Any URI proposed must at minimum support the 15 character ASCII in  
> the ANSI specs. The called party's proxy then must be able to parse  
> not only the policy of what can and cannot be displayed but also  
> what the CU/A is capable of dealing with and not creating too much  
> processing overhead for the called parties proxy.
>
> capabilities of the mobile CUA you sent the MMS object directly to  
> the MMSC without knowing if the CUA could even display the object.
>
> This is clearly a vastly more interesting subject than classic  
> Caller Display Name.
>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 15 Jan 2006 18:44:28 -0500

> means (i.e. not under the control of the calling party).

Yes if the calling party is on the PSTN then they are not in direct 
control of the Caller Display name for that number.

This is another of those wonderful NO TCAP ID we're so fond of.

> (which DOES know its own display capabilities authoritatively) and

HTTP and what HTML, XML?

> destination, or some means for the callee to get that URI.

yes In the PSTN policy is maintained by the calling party as to whether 
the Display Name Information is passed to the called party.

This BTW is not currently available in SIP.

There has been a interesting discussion in SIPPING of how can a called 
party deal with anonymous calls.

> a proxy - this, however, is not at all clear.

yes sorry ...

> your confusedly (as we trialled a super-CLI with ENUM that in the UK),

Really ? HTML based?

>> ANSI specs. The called party's proxy then must be able to parse not 
>> only the policy of what can and cannot be displayed but also what the 
>> CU/A is capable of dealing with and not creating too much processing 
>> overhead for the called parties proxy.
>>

--

---

From: lconroy <[email-masked]>
Date: Mon, 16 Jan 2006 01:38:51 +0000

On 15 Jan 2006, at 23:44, Richard Shockey wrote:
> <snip>

The stored web page need not be very complex at all, and can be totally
pre-generated - holding something like a img tag pointing to a picture
on flikr, plus the caller's name (text) as the alt parameter.

In our tests we cheated by having the web page title as the name of the
caller, so for a REALLY bad hack, one could just look at the http: URI
and extract the leaf file name without all that messy HTTP transaction
stuff - ugly, but OK in our environment. For a "richer experience", I'm
AssUMing that the recipient can do HTTP/HTML (i.e there is a web client
or browser available). We knocked up a set of HTML pages in our tests,
but XML would be fine.

> yes In the PSTN policy is maintained by the calling party as to  
> whether the Display Name Information is passed to the called party.
>
> There has been a interesting discussion in SIPPING of how can a  
> called party deal with anonymous calls.

There has indeed :).

>> a proxy - this, however, is not at all clear.

I thought so - in that case, maybe the file name hack will get wider  
use.
The gateway can do an ENUM lookup, and find the text associated with  
that
web entry. Hurl.

>> your confusedly (as we trialled a super-CLI with ENUM that in the  

Remember - we were using a stand-alone ENUM client that we hooked into
a proprietary SIP program - the ENUM client was passed the From: with an
incoming call, broke out the userpart, treated that as a telephone  
number,
and did an ENUM lookup.

If there was a web:http NAPTR in the queried ENUM zone, the ENUM client
triggered an HTTP get and the page was displayed.
(as mentioned, the early demo just displayed the leaf file name it  
found in
  the web NAPTR). All the code was Deeply Ugly, but it WAS a proof-of- 
concept.

The key point is that a SIP program is not just a SIP UAS. SIP as a  
protocol
can't hack it, but that doesn't mean that the program can't use other  
mechanisms
- an ENUM client is pretty small, and firing up a browser is  
relatively trivial
on Windoz and on real operating systems.

[Hence the major warnings in TS 102.172 and in RFC 4002 :]

Finally, as in all these things there's a user ENUM way (we tested it)
and an Infrastructure ENUM way - I guess that PSTN is the latter, and if
you went for an ENUM approach zones would not be accessible to the  
public.

If callers DO have user ENUM, then the callee must not get any telephone
number or they can do the lookup (even if the call comes in on the steam
line).

The effect that the CEO's mug shot appearing on a PC screen has on phone
call answering technique is quite impressive.

all the best,
   Lawrence

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jan 2006 08:37:17 -0500

I can no longer figure out what this discussion is about - it seems to 
be all over the map.

I see several distinct issues here:

- sip caller identity issues:

   . what information in an incoming sip request does the
     recipient use as identifying info about the caller?

   . given that the identity info has been isolated from
     the request, what is displayed to the called user?

- dealing with calls from PSTN to a sip environment:

   . how is the info from the pstn environment transformed
     into sip identity information?

- dealing with calls from a sip environment to the PSTN

   . how is info from the sip environment transformed
     into info that causes the right thing to happen in
     the pstn environment

I *thought* this CNAM proposal was just about transformations from the 
PSTN environment to the sip environment.

The whole discussion of vcard seems to have strayed into sip caller 
identity issues.

One think I would like ensure is that a callee in a sip environment not 
need to do something different when receiving a call from the PSTN than 
it does when receiving a native sip call.

	Paul

lconroy wrote:
> I thought so - in that case, maybe the file name hack will get wider  use.
> The gateway can do an ENUM lookup, and find the text associated with  that
> web entry. Hurl.
> 
> incoming call, broke out the userpart, treated that as a telephone  number,
> and did an ENUM lookup.
> 
> - an ENUM client is pretty small, and firing up a browser is  relatively 
> trivial
> you went for an ENUM approach zones would not be accessible to the  public.
>

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 16 Jan 2006 15:08:21 +0100

> call answering technique is quite impressive.

*If* this happens in normal User ENUM then the owner of the number can put
any information into his ENUM domain, including wrong CNAM setting.

Imagine the pranks one can play with this.

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >