> But this section 8 is written so generically (eg "However, > any specific behavior is specific to implementations or > services") that it is pretty much saying nothing on > the usage of From header vs P-Asserted-ID.
8. User Agent Server Behavior Typically, a user agent renders the value of a P-Asserted-Identity header field that it receives to its user. It may consider the identity provided by a Trust Domain to be privileged, or intrinsically more trustworthy than the From header field of a request. However, any specific behavior is specific to implementations or services. This document also does not mandate any user agent handling for multiple P-Asserted-Identity header field values that happen to appear in a message (such as a SIP URI alongside a tel URL). However, if a User Agent Server receives a message from a previous element that it does not trust, it MUST NOT use the P-Asserted- Identity header field in any way. If a UA is part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can use the value freely but it MUST ensure that it does not forward the information to any element that is not part of the Trust Domain, if the user has requested that asserted identity information be kept private. If a UA is not part of the Trust Domain from which it received a message containing a P-Asserted-Identity header field, then it can assume this information does not need to be kept private. > On a feature as simple as which header to use for caller > ID display, so one carrier can try to enforce the From > header while another could use the P-Asserted-ID? It is all about trust. The trust issues were one of the reasons why RFC 5876 is categorized as "Informational" instead of "Standards Track". > Is there no standard pertaining to SIP in IETF and ITU > which clarifies the proper usage? Concerning IETF, see Abstract. 3gpp may be more specific concerning the topic. Abstract This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
