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
