Re: [Sip] draft-elwell-sip-identity-handling-ua-00 posted

["Elwell, John" <john.elwell at siemens.com>]

Paul,

Thanks for your early read of this draft. Points taken.

John 

> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
> Behalf Of Paul Kyzivat
> Sent: 01 October 2008 16:01
> To: Elwell, John
> Cc: sip at ietf.org
> Subject: Re: [Sip] draft-elwell-sip-identity-handling-ua-00 posted
> 
> John,
> 
> I really like this document! I think it is important.
> 
> A few comments:
> 
>     Furthermore, although a P-Asserted-Identity header field 
> can contain
>     a display-name, the assertion strictly speaking covers 
> only the URI,
>     and therefore the display-name is even less trustworthy 
> than the URI.
> ...
>     If a display-name is received, the general advice is not 
> to present
>     it to the user.  Presenting an authenticated identifier 
> along with an
>     unauthenticated display-name would be misleading.  A preferred
>     solution is to obtain a name by phone-book look-up, based on the
>     received authenticated identifier, and present that.  If an
>     unauthenticated identifier is presented (and indicated as 
> not to be
>     trusted), little additional harm would arise from also 
> presenting the
>     display-name.
> 
> In services that are providing traditional telephony services, 
> calling-name is often an important feature. When the services are 
> provided via sip, the display name seems to be the only 
> obvious choice 
> for conveying calling-name to the callee.
> 
> A provider that needs to do this *can* police the use of 
> display-name in 
>  From and/or manage its use of display-name in 
> P-Asserted-Identity. In 
> such an environment, the display-name could be trusted by the 
> UAS to the 
> same extent that the rest of the identity is.
> 
> If there is an alternative source of info, such as a local phone book 
> with a matching entry, then it would seem good to prefer 
> that. If there 
> is no alternative source, and the display-name is not 
> trusted, then it 
> may still be better to display it than not. Especially if some 
> indication of distrust can be rendered with it.
> 
>     When a UA receives more than one caller identifier, the choice of
>     which one to present to the user will be influenced by
>     trustworthiness.  Generally the most trustworthy should be chosen.
>     When two of equal trust are received (e.g., a TEL URI and 
> a SIP URI
>     in the P-Asserted-Identity header field), there may be grounds for
>     presenting each (or elements of each), if this is 
> possible, because
>     either or both could be of use to the user.
> 
> Another consideration is the context in which the identifier is 
> displayed. In some cases the display is predicated on the 
> identity being 
> a number. In such a case there will be a bias towards 
> displaying either 
> a type 1 address or the user portion of a type 2 address.
> 
> 	Thanks,
> 	Paul
> 
> Elwell, John wrote:
> > This draft arose out of suggestions during SIP Identity 
> discussions in
> > the SIP WG in Dublin that we should consider UA handling of received
> > identity information.
> > 
> http://www.ietf.org/internet-drafts/draft-elwell-sip-identity-
> handling-u
> > a-00.txt
> > 
> > John
> > _______________________________________________
> > Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org for new developments on the application of sip
> > 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip