Re: 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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip