From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3939.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc3939.txt (limited to 'doc/rfc/rfc3939.txt') diff --git a/doc/rfc/rfc3939.txt b/doc/rfc/rfc3939.txt new file mode 100644 index 0000000..ff04931 --- /dev/null +++ b/doc/rfc/rfc3939.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group G. Parsons +Request for Comments: 3939 J. Maruszak +Category: Standards Track Nortel Networks + December 2004 + + + Calling Line Identification for Voice Mail Messages + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document describes a method for identifying the originating + calling party in the headers of a stored voice mail message. Two new + header fields are defined for this purpose: Caller_ID and + Called_Name. Caller_id is used to store sufficient information for + the recipient to callback, or reply to, the sender of the message. + Caller-name provides the name of the person sending the message. + + + + + + + + + + + + + + + + + + + + + + + +Parsons & Maruszak Standards Track [Page 1] + +RFC 3939 Calling Line Identification December 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in this Document. . . . . . . . . . . . . . . 3 + 3. Calling Line Identification Field. . . . . . . . . . . . . . . 3 + 3.1. Internal Call. . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. External Call. . . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Numbering Plan . . . . . . . . . . . . . . . . . . . . . 4 + 3.4. Date Header. . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Caller Name Field. . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Formal Syntax. . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1. Calling Line Identification Syntax . . . . . . . . . . . 6 + 5.2. Caller Name Syntax . . . . . . . . . . . . . . . . . . . 6 + 5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Other Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7 + 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 7 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 9.2. Informative References . . . . . . . . . . . . . . . . . 8 + 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 11 + +1. Introduction + + There is currently a need for a mechanism to identify the originating + party of a voice mail message, outside of the "FROM" header + information. The telephone number and name of the caller are + typically available from the telephone network, but there is no + obvious header field to store this in an Internet Mail message. + + This information is intended for use when the VPIM message format is + used for storing "Call Answer" voice messages in an Internet Mail + message store, i.e., the calling party leaves a voice message for the + recipient, who was unable to answer the call. The implication is + that there is no RFC 2822 address known for the originator. + + [VPIMV2R2] suggests the originating number be included as an Internet + address, using the first method shown below. There are several other + ways to store this information, but they all involve some + manipulation of the "From" field. For example: + + 1. From: "416 555 1234" + 2. From: "John Doe" <4165551234@host> + 3. From: unknown:; + + + + + +Parsons & Maruszak Standards Track [Page 2] + +RFC 3939 Calling Line Identification December 2004 + + + Since any of these is a forced translation, it would be useful to + store the calling party's name and number as presented by the + telephone system to the called party without manipulation. This + would allow the calling party's information to be displayed to the + recipient (similar to it appearing on the telephone) and also allow + future determination of an Internet address for the originator (if + one exists). Note that there is no requirement to store meta-data + (e.g., type of number, presentation restricted), as this information + is not presented to the called party and is generally not available + to voice mail systems. The intent is to store the available + information to an analog (non-ISDN) phone (e.g., per [T1.401] in + North America). + + [RFC2076] currently lists "phone" as an Internet message header which + would hold the originating party's telephone number, but it is listed + as "non-standard", i.e., usage of this header is not generally + recommended. It also has no defined format, making the information + unparsable. There is no similar entry for the originator's name. + + It is proposed that two new message header fields be included to hold + this information, namely the Calling Line Identification ("Caller- + ID") and Caller Name ("Caller-Name"). + +2. Conventions Used in this Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, [RFC2119]. + +3. Calling Line Identification Field + + The Calling Line Identification header ("Caller-ID") holds sufficient + information for the recipient's voice mail system to call back, or + reply to, the sender of the message. The number that is contained in + this header is supplied by the telephone system. The exact format of + the data received depends on the type of call, that is -- internal or + external call. + + Note that for both options, the number field MUST contain only the + digits of the number and MUST be representable using the American + Standard Code for Information Interchange [ASCII] character set; it + does not include any separating character (e.g., "-"). + + It is expected that default, likely to be the most common case, will + not have any numbering plan semantic associated with the number. + However, in the case that it is known, an optional "NumberingPlan" + parameter MAY be used to indicate the semantic. + + + + +Parsons & Maruszak Standards Track [Page 3] + +RFC 3939 Calling Line Identification December 2004 + + +3.1. Internal Call + + For an internal call (e.g., between two extensions within the same + company), it is sufficient to relay only the extension of the calling + party, based on the company dialing plan. + + However, the support of longer numbers may be supported by the + enterprise phone system. + +3.2. External Call + + For an international call, the calling party's number must be the + full international number as described in [E.164], i.e., Country Code + (CC), National Destination Code (NDC), and Subscriber Number (SN). + Other information, such as prefixes or symbols (e.g., "+"), MUST NOT + be included. [E.164] allows for numbers of up to 15 digits. + + For a call within North America, it is also suggested that 15 digits + per [T1.625] be supported. However, some service providers may only + support 10 digits as described in [T1.401] and [GR-31-CORE]. Though + it is desirable that an international number not be truncated to 10 + digits if it contains more, it is recognized that limitations of + various systems will cause this to happen. + + Implementors of this specification should be aware that some phone + systems are known to truncate international numbers, even though this + behavior is undesirable. + + Note that the other defined fields available to non-analog systems + (e.g., subaddress, redirecting number), as well as the meta-data, are + not intended to be stored in this header. + +3.3. Numbering Plan + + In this baseline case (i.e., analog lines), no numbering plan + information is known or implied. However, in the case that a + numbering plan is known, an optional "NumberingPlan" parameter MAY be + used to indicate the semantic. Only three semantics are defined: + "unknown", "local", and "e164". "unknown" is the default if no + numbering plan semantic is known (and the default if the parameter is + absent). "local" has meaning only within the domain of the voice + mail system that stored the message (i.e., the voice mail system + knows that the number belongs to a local numbering plan). "e164" + indicates that the number is as described in [E.164]. "x-" may be + used to indicate enterprise or service specific dialing plans. + + + + + + +Parsons & Maruszak Standards Track [Page 4] + +RFC 3939 Calling Line Identification December 2004 + + +3.4. Date Header + + The date and time may be included by the telephone system with the + calling party's telephone number per [T1.401]. This MAY be used, as + there is an existing "Date" Internet header to hold this information. + It is a local implementation decision whether this time or the local + system time will be recorded in the "Date" header. + +4. Caller Name Field + + The name of the person sending the message is also important. + Information about whether the call is internal or external may be + included if it is available. This information may not be available + on international calls. + + Further, the exact format for this field is typically a service + provider option per [T1.641]. It is possible for the caller's name + to be sent in one of several character sets depending on the service + provider signaling transport (e.g., ISDN-UP, SCCP, TCAP). These + include: + + 1) International Reference Alphabet (IRA), formerly know as + International Alphabet No.5 or IA5 [T.50] + 2) Latin Alphabet No. 1 [8859-1] + 3) American National Standard Code for Information Interchange + [ASCII] + 4) Character Sets for the International Teletex Service [T.61] + + Of these, the IRA and T.61 character sets contain a number of options + that help specify national and application oriented versions. If + there is no agreement between parties to use these options, then the + 7-bit character set in which the graphical characters of IRA, T.61, + and ASCII are coded exactly the same, will be assumed. Further, the + 7-bit graphical characters of [8859-1] are the same as in [ASCII]. + + Note that for delivery to customer equipment in North America, the + calling name MUST be presented in ASCII per [T1.401]. + + As a result, for the caller name header defined in this document, + characters are represented with ASCII characters. However, if a name + is received that cannot be represented in 7-bit ASCII, it MAY be + stored using its native character set as defined in [RFC2047]. + + In telephone networks, the length of the name field MUST NOT exceed + 50 characters, as defined in [T1.641]. However, service providers + may choose to further limit this to 15 characters for delivery to + customer equipment, e.g., [T1.401] and [GR-1188-CORE]. + + + + +Parsons & Maruszak Standards Track [Page 5] + +RFC 3939 Calling Line Identification December 2004 + + +5. Formal Syntax + + Both Calling Line Identification and Caller Name follow the syntax + specification using the augmented Backus-Naur Form (BNF) as described + in [RFC2234]. While the semantics of these headers are defined in + sections 4 and 5, the syntax uses the 'unstructured' token defined in + [RFC2822]: + + unstructured = *([FWS] utext) [FWS] + +5.1. Calling Line Identification Syntax + + "Caller-ID" ":" 1*DIGIT [ "," "NumberingPlan=" + ( "unknown" / "local" / "e164" / ietf-token / x-token ) ] CRLF + + ietf-token := + + x-token := + +5.2. Caller Name Syntax + + "Caller-Name" ":" unstructured CRLF + +5.3. Examples + + To: +19725551212@vm1.example.com + Caller-ID: 6137684087 + Caller-Name: Derrick Dunne + + To: 6137637582@example.com + Caller-ID: 6139416900 + Caller-Name: Jean Chretien + +6. Other Considerations + +6.1. Compatibility with Other Internet Phone Numbers + + The intent of these headers are to record telephone number that is + sent by the analog phone system with an incoming call without + alteration or interpretation. If sufficient semantic is known or can + be inferred, this may be included in the NumberingPlan field. This + may allow it to be later translated into an addressable phone number. + Addressable or dialable phone numbers (which this document does not + define) are defined in other documents, such as GSTN address + [RFC3191] or telephone URL [RFC2806]. + + + +Parsons & Maruszak Standards Track [Page 6] + +RFC 3939 Calling Line Identification December 2004 + + +6.2. Usage + + There are a few scenarios of how this mechanism may fail that must be + considered. The first is mentioned in section 3.2 - the truncation + of an international number to 10 digits. This could result in a + misinterpretation of the resulting number. For instance, an + international number (e.g., from Ireland) of the form "353 91 73 + 3307" could be truncated to "53 91 73 3307" if received in North + America, and interpreted as "539 917 3307" - a seemingly "North + American" style number. Thus, the recipient is left with incorrect + information to reply to the message, possibly with an annoyed callee + at the North American number. + + The second scenario is the possibility of sending an internal + extension to an external recipient when a Call Answer message is + forwarded. This poses two problems, the recipient is given the wrong + phone number, and the company's dialing plan could be exposed. + + The final concern deals with exercising character options that are + available in coding the Calling Name field. An international system + may send a message with coding options that are not available on the + receiving system, thus giving the recipient an incorrect Caller Name. + +7. Security Considerations + + Note that unlisted and restricted numbers are not a concern as these + header fields are defined to contain what the called party would see + (e.g., 'Private Name'), as opposed to the complete details exchanged + between service providers. + + However, it must also be noted that this mechanism allows the + explicit indication of phone numbers in the headers of an email + message (used to store voice messages). While the rationale for this + is reviewed in section 1, the recipient of this message may not be + aware that this information is contained in the headers unless the + user's client presents the information. Its use is intended to be + informative as it is when it appears on a telephone screen. + +8. IANA Considerations + + This document defines an IANA-administered registration space for + Caller-ID numbering plans in section 5.1. Each registry entry + consists of an identifying token and a short textual description of + the entry. There are three initial entries in this registry: + + unknown - The number's semantics are unknown. This value is the + default in the absence of this parameter. + + + + +Parsons & Maruszak Standards Track [Page 7] + +RFC 3939 Calling Line Identification December 2004 + + + local - The number only has meaning within the domain of the + sending system identified by the RFC 2822 From field of + the message. + + e164 - The number's semantics are described in [E.164]. + + The only way to add additional entries (ietf-token in section 5.1) to + this registry is with a standards-track RFC. + +9. References + +9.1. Normative References + + [VPIMV2R2] Vaudreuil, G. and G. Parsons, "Voice Profile for + Internet Mail - version 2 (VPIMv2)", RFC 3801, June + 2004. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions for + Non-ASCII Text ", RFC 2047, November 1996. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +9.2. Informative References + + [RFC2076] Palme, J., "Common Internet Message Headers", RFC + 2076, February 1997. + + [E.164] ITU-T Recommendation E.164 (1997), "The international + public telecommunication numbering plan" + + [T.50] ITU-T Recommendation T.50 (1992), "International + Reference Alphabet (IRA)" + + [T.61] CCITT Recommendation T.61 (1988) (Withdrawn), + "Character Repertoire and Coded Character Sets for the + International Teletex Service" + + + + + + + +Parsons & Maruszak Standards Track [Page 8] + +RFC 3939 Calling Line Identification December 2004 + + + [8859-1] ISO/IEC International Standard 8859-1 (1998), + Information Technology _ 8-bit single-byte coded + graphic character sets _ Part 1: Latin Alphabet No. 1 + + [ASCII] American National Standards Institute (ANSI), Coded + Character Set - 7-Bit American National Standard Code + for Information Interchange, ANSI X3.4, 1986. + + [T1.401] American National Standards Institute (ANSI), + Telecommunications _ Network-to-Customer Installation + Interfaces _ Analog Voicegrade Switched Access Lines + with Calling Number Delivery, Calling Name Delivery, + or Visual Message-Waiting Indicator Features, ANSI + T1.6401.03-1998 + + [T1.625] American National Standards Institute (ANSI), + Telecommunications - Integrated Services Digital + Network (ISDN) _ Calling Line identification + Presentation and Restriction Supplementary Services, + ANSI T1.625-1993 + + [T1.641] American National Standards Institute (ANSI), + Telecommunications - Calling Name Identification + Presentation, ANSI T1.641-1995 + + [GR-1188-CORE] Telcordia Technologies, "CLASS Feature: Calling Name + Delivery Generic Requirements", GR-1188-CORE, Issue 2, + December 2000 + + [GR-31-CORE] Telcordia Technologies, "CLASS Feature: Calling Number + Delivery", GR-31-CORE, Issue 1, June 2000 + + [RFC3191] Allocchio, C., "Minimal GSTN address format in + Internet Mail", RFC 3191, October 2001. + + [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, + April 2000. + +10. Acknowledgments + + The previous authors of versions of this document were Derrick Dunne + and Jason Collins. The current authors would like to thank Derrick + and Jason for their contributions. + + + + + + + + +Parsons & Maruszak Standards Track [Page 9] + +RFC 3939 Calling Line Identification December 2004 + + +Authors' Addresses + + Glenn Parsons + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + + Phone: +1-613-763-7582 + EMail: gparsons@nortelnetworks.com + + + Janusz Maruszak + + Phone: +1-416-885-0221 + EMail: jjmaruszak@sympatico.ca + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Parsons & Maruszak Standards Track [Page 10] + +RFC 3939 Calling Line Identification December 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Parsons & Maruszak Standards Track [Page 11] + -- cgit v1.2.3