doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

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" <non-mail-user@host>
+      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 := <An extension token defined by a
+                       standards-track RFC and registered
+                       with IANA.>
+
+        x-token := <The two characters "X-" or "x-" followed, with
+                    no intervening white space, by any 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]
+