draft-cooke-sip-rfc3261bis-02 Internet-Draft R. Cooke Intended status: Informational June 2, 2023 Expires: December 4, 2023 Note on Usage of Phone Number in the From Field of SIP Messaging V Abstract This document proposes adding a note to the current SIP messaging standards to clarify the usage of the phone number within the From field. The note advises against duplicating the phone number inside the double quotation marks (" ") when it is already included within the double angle brackets (<>). This recommendation aims to avoid the display of unknown numbers caused by devices prioritizing SIP signaling information over locally stored contact information. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at https://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at https://www.ietf.org/shadow.html Note on Copyright Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction......................................................3 2. Terminology.......................................................3 3. The From Header Field.............................................4 4. Examples..........................................................4 5. Rationale.........................................................5 6. Compatibility and Impact..........................................5 7. Security Considerations...........................................6 8. References........................................................6 9. Author's Address.................................................10 1. Introduction The From header field in Session Initiation Protocol (SIP) messaging is used to indicate the initiator of a SIP request. It typically includes a display name and a SIP or tel URI. The display name is enclosed within double quotation marks (" ") and the URI is enclosed within double angle brackets (<>). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. The From Header Field Update to 8.1.1.3 From in RFC 3261. The From header field indicates the logical identity of the initiator of the request, potentially the user's address-of-record. It comprises a URI and an optional display name. The From field is used by SIP elements to determine the applicable processing rules for a request, such as automatic call rejection. Therefore, it is crucial to avoid including IP addresses or the fully qualified domain name (FQDN) of the User Agent (UA) host in the From URI, as these are not logical names. The From header field permits the inclusion of a display name. It is recommended that a User Agent Client (UAC) refrain from using the user's phone number as the display name within the From field, as this is not a logical name and it is already included. This practice eliminates the possibility of duplication and potential confusion. Instead, if the identity of the client is intended to remain hidden, the UAC SHOULD use the display name "Anonymous" along with a syntactically correct, but otherwise meaningless URI (e.g., sip:thisis@anonymous.invalid). Typically, the value in the From header field of requests generated by a specific UA is pre-provisioned by the user or the administrators of the user's local domain. In cases where a UA is utilized by multiple users, it may support switchable profiles that incorporate a URI corresponding to the profiled user's identity. Recipients of requests can authenticate the originator by verifying that the information in the From header field matches the claimed identity (see Section 22 for more details on authentication). The From field MUST include a new "tag" parameter chosen by the UAC. For detailed instructions on selecting a tag, refer to Section 19.3 (RFC 3261). Additional information about the From header field can be found in Section 20.20 (RFC 3261). 4.Examples: From: "Bob" sips:bob@biloxi.com;tag=a48s From: sip:+12125551212@phone2net.com;tag=887s From: Anonymous sip:c8oqz84zk7z@privacy.org;tag=hyh8 Bad Example: From: "5551234567" sip:5551234567@example.com;tag=12345 Explanation: In this example, the From header field includes the user's phone number within the display name. This practice can lead to confusion and display issues on certain devices that prioritize SIP signaling information over locally stored contact information. Consequently, the recipient may perceive the call as originating from an unknown number, even though the user's name is displayed. It is strongly discouraged to include the phone number within the display name, as it undermines meaningful caller identification and can create a negative user experience. The From header field is defined in Section 8.1.1.3 of RFC 3261 [RFC3261]. It is used to indicate the initiator of a SIP request and contains a display name and a SIP or tel URI. The display name is typically used to convey the caller's name or a recognizable identifier. It is enclosed within double quotation marks (" "). The URI includes the SIP or tel scheme followed by the user's address, enclosed within double angle brackets (<>) to indicate a URI. In some cases, the display name includes the phone number in addition to the caller's name. However, it is important to note that including the phone number within the display name can lead to confusion and display issues on certain devices that prioritize SIP signaling information over locally stored contact information. Consequently, the recipient may perceive the call as originating from an unknown number, even though the user's name is displayed. 5. Rationale Including the phone number within the display name of the From header field is unnecessary and can lead to display issues on certain devices. The display name is primarily used to convey the caller's name or a recognizable identifier, while the URI contains the necessary contact information. By avoiding the duplication of the phone number within the display name, we ensure that devices prioritize the locally stored contact information and display the caller's name instead of an unknown number. 6. Compatibility and Impact This note on the usage of the From header field has no impact on the interoperability between SIP implementations. It is intended to provide clarification and best practices to improve the user experience. 7. Security Considerations This document does not introduce any new security considerations beyond those already discussed in the SIP specifications [RFC3261]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol" , RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9. Author's Address Raymond Cooke BT Email: raymondcooke@hotmail.co.uk