doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3601.txt b/doc/rfc/rfc3601.txt
new file mode 100644
index 0000000..61432dc
--- /dev/null
+++ b/doc/rfc/rfc3601.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       C. Allocchio
+Request for Comments: 3601                                    GARR-Italy
+Category: Standards Track                                 September 2003
+
+
+              Text String Notation for Dial Sequences and
+       Global Switched Telephone Network (GSTN) / E.164 Addresses
+
+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 (2003).  All Rights Reserved.
+
+Abstract
+
+   This memo describes the full set of notations needed to represent a
+   text string in a Dial Sequence.  A Dial Sequence is normally composed
+   of Dual Tone Multi Frequency (DTMF) elements, plus separators and
+   additional "actions" (such as "wait for dialtone", "pause for N
+   secs", etc.) which could be needed to successfully establish the
+   connection with the target service:  this includes the cases where
+   subaddresses or DTMF menu navigation apply.
+
+1.  Introduction
+
+   Since the very first devices interacting with GSTN services appeared,
+   a need for a unique text string representation of commonly called
+   telephone numbers, and more generally DTMF sequences and actions, was
+   foreseen.
+
+   This memo describes the full text string representation method.  This
+   specification was explicitly created to provide an easy, unique and
+   complete reference which MUST be used by all other specifications
+   needing a text string representation for a Dial Sequence.
+
+   The specification was collected directly from Dial Sequence
+   definitions which are already described in existing Standard Track
+   specifications (such as [6] [7] [8] [9]), and is fully synchronized
+   with them.  Full compatibility is thus assured, and as a consequence,
+   this specification results in a compendium of existing definitions.
+
+
+
+
+Allocchio                   Standards Track                     [Page 1]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+   This notation is a fully compatible compendium of existing notations,
+   and should be used in all specifications needing a text string
+   representation of a Dial Sequence.
+
+   Although the commonly called "telephone numbers" are normally used to
+   generate a Dial Sequence when establishing a connection, the full
+   abstract E.164 addresses [2], i.e., the universal addressing on the
+   Global Switched Telephone Network (GSTN), have further elements which
+   cannot be dialled.  Thus abstract E.164 addresses cannot be fully
+   converted into a Dial Sequence or fully represented using this
+   notation.
+
+1.1.  Terminology and Syntax conventions
+
+   In this document the formal definitions are described using ABNF
+   syntax, as defined in [3].  This memo also uses some of the "CORE
+   DEFINITIONS" defined in "APPENDIX A - CORE" of that 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, RFC 2119 [4].
+
+   The following terms are also defined in this document:
+
+      Dial Sequence:
+         a series of DTMF elements and human or device "actions";
+
+      phone-string:
+         a text representation of a Dial Sequence;
+
+      GSTN address:  a commonly called "telephone number" on the GSTN,
+         i.e., a diallable subset of an E.164 abstract address or any
+         private numbering schema diallable address;
+
+      gstn-phone:
+         a text representation of a GSTN address;
+
+      subaddr-string:
+         a text representation of a GSTN subaddress (which includes ISDN
+         subaddresses [2] and T.33 subaddresses [5]);
+
+      post-dial:
+         a text representation of a post dialling sequence.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 2]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+2.  The "Dial Sequence" definition
+
+   The possible elements composing a Dial Sequence can vary from a
+   minimum number, up to a really large and complex collection: in fact,
+   the sequences already needed to dial a gstn-phone, which is a subset
+   of the generic Dial Sequence, well represents this variety and
+   complexity of cases.
+
+   In particular, a Dial Sequence is composed by:
+
+   -  "DTMF elements": normally available as "keys" on numeric keypads
+      of dialling devices;
+
+   -  "actions": normally performed by the agent (human or device)
+      composing the Dial Sequence;
+
+   -  "separators": used only to improve human readability of a Dial
+      Sequence.
+
+2.1.  The "phone-string" definition
+
+   The text representation of the Dial Sequence elements is defined in
+   the phone-string specification:
+
+      phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+      DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+                     ; special DTMF codes like "*", "#", "A", "B",
+                     ; "C", "D" are defined in [1].
+                     ; Important Note: these elements only apply for
+                     ; alphabetic strings used in DTMF operations.
+                     ; They are NOT applicable for the alphabetic
+                     ; characters that are mapped to digits on phone
+                     ; keypads in some countries.
+
+      pause = "p"
+
+      tonewait = "w"
+
+      written-sep = ( "-" / "." )
+
+   Note:
+      DTMF are the "DTMF elements", pause and tonewait are the "actions"
+      and written-sep are the "separators".
+
+   The "pause" and "tonewait" elements interpretation of the phone-
+   string depends on the specific devices and implementation using the
+   specification.  Thus their exact meaning is not mandated in this
+
+
+
+Allocchio                   Standards Track                     [Page 3]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+   document.  The next section provides some examples drawn from common
+   practice.  Both "pause" and "tonewait" are case insensitive.
+
+   Implementation of "pause" and "tonewait":
+
+      -  one instance of a "pause" SHOULD be interpreted as a pause of
+         one second between the preceding and succeeding dial string
+         elements;
+
+      -  a "tonewait" SHOULD be interpreted as a pause that will last
+         until the calling party hears a dial tone or another indication
+         that more dial string characters may be processed.  An off-hook
+         indication MAY also be interpreted as this kind of indication
+         (meaning that the audio channel has been opened to the
+         receiving party);
+
+      -  because these characters are not a part of the GSTN subscriber
+         address (telephone number) per se, any dial string characters
+         that succeed either a "pause" or "tonewait" SHOULD be sent
+         using DTMF signalling.
+
+   The use of written-sep elements is allowed in order to improve human
+   readability of the phone-string.  The written-sep are elements which
+   can be placed between dial elements, such as digits etc.  Any
+   occurrences of written-sep elements in a phone-string MUST NOT result
+   in any action.  Conformant implementations MAY drop or insert
+   written-sep into the phone-string they handle.
+
+   The phone-string definition is used in the following sections to
+   explicitly describe the encoding of some specific subcases where it
+   applies.
+
+3.  The "gstn-phone" definition
+
+   In order to access a GSTN address, a human or a device must perform a
+   Dial Sequence.  Thus, a GSTN address can be represented using the
+   phone-string elements.  In particular, diallable E.164 numeric
+   addresses [2] represent a limited subset of all possible GSTN
+   addresses, while the complete complex case needs a full encoding
+   schema, as it also includes a local or private addressing schema.
+
+   In order to describe this distinction and provide anyhow a complete
+   encoding schema, the following definition of "gstn-phone" is
+   provided:
+
+      gstn-phone = ( global-phone / local-phone )
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 4]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+3.1.  The "global-phone" definition
+
+   The purpose of the global-phone element is to represent diallable
+   E.164 numeric addresses.  As such, it uses a subset of a phone-string
+   definition only.
+
+   The syntax for a global-phone element is as follows:
+
+      global-phone = "+" 1*( DIGIT / written-sep )
+
+   Any other dialling schemes MUST NOT use the leading "+" defined here.
+   The "+" sign is strictly reserved for the standard "global-phone"
+   syntax, and, even if not specifically part of the phone-string
+   definition, it is needed to uniquely label a global-phone.
+
+3.2.  The "local-phone" definition
+
+   The local-phone element is intended to represent the set of possible
+   cases where the global-phone numbering schema does not apply.  Given
+   the different and complex conventions currently being used in the
+   GSTN system, the local-phone definition supports a large number of
+   elements.
+
+   The detailed syntax for local-phone elements is as follows:
+
+      local-phone =  [ exit-code ] dial-number
+
+      local-phone =/ exit-code [ dial-number ]
+
+      exit-code = phone-string
+                  ; this will include elements such as the digit to
+                  ; access outside line, the long distance carrier
+                  ; access code, the access password to the service,
+                  ; etc...
+
+      dial-number = phone-string
+                  ; this is in many cases composed of different elements
+                  ; such as the local phone number, the area code
+                  ; (if needed), the international country code
+                  ; (if needed), etc...
+
+   Notes:
+      The "+" character is reserved for use in a global-phone and MUST
+      NOT be used in a local-phone string;
+
+      Please note that a local-phone string MUST NOT be a null string,
+      i.e., at least an exit-code, or a dial-number or both MUST be
+      present.
+
+
+
+Allocchio                   Standards Track                     [Page 5]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+4.  The "subaddr-string" definition
+
+   In GSTN service, there are cases where a subaddress is required to
+   specify the final destination.  To specify these subaddresses, a Dial
+   Sequence is also used, and thus the "subaddr-string" can be encoded
+   as:
+
+      subaddr-string = phone-string
+
+   Note:
+      Within actual uses of subaddresses, some specific services can
+      limit the possible set of phone-string elements allowed.  In
+      particular, there are ISDN subaddresses [2] [8], which restrict
+      the phone-string elements to 1*( DIGIT / written-sep ) and service
+      specific subaddresses, like the fax service T.33 subaddress [5]
+      [7], which restrict phone-string elements to 1*( DIGIT ).
+
+5.  The "post-dial" definition
+
+   In some cases, after the connection with the destination GSTN device
+   has been established, a further dialling sequence is required to
+   access further services.  A typical example is an automated menu-
+   driven service using DTMF sequences. These cases may be represented
+   using the "post-dial" definition below:
+
+      post-dial = phone-string
+
+6.  Examples
+
+   In order to clarify the specification we present, here are a limited
+   set of examples.  Please note that all the examples are for
+   illustration purposes only.
+
+   A GSTN address in Italy, dialled from U.S.A., using local-phone,
+   without written-sep:
+
+      01139040226338
+
+   A GSTN address in Germany, using global-phone and written-sep ".":
+
+      +49.81.7856345
+
+   A GSTN address in U.S.A. using global-phone and written-sep "-":
+
+      +1-202-455-7622
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 6]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+   A post-dial sequence, pausing, dialling 1, waiting for dial tone,
+   dialling 7005393, waiting again for dial tone and dialling 373; note
+   the use of four "p" elements (pppp) to specify a longer initial
+   pause:
+
+      pppp1w7005393w373
+
+   A Dial Sequence in Italy (long distance call), using local-phone,
+   with exit-code "9", long distance access "0", area code "40", pause
+   "p" and written-sep ".":
+
+      9p040p22.63.38
+
+   A Dial Sequence using exit-code "0", a wait for dial tone, local-
+   phone for an International "800" toll-free number dialled from
+   Belgium (international prefix "00"), and a post-dial sequence to
+   access a voice mailbox with userID "334422" and Personal
+   Identification Number (PIN) code "1234":
+
+      0w00800-39380023pp334422p1234
+
+7.  Conclusions
+
+   This proposal creates a full standard text encoding for Dial
+   Sequences, including GSTN and diallable E.164 addresses, and thus
+   provides a unique common representation method both for standard
+   protocols and applications.
+
+   Some definitions, like these corresponding to an alias of the generic
+   phone-string element, are somewhat a theoretical distinction; however
+   they are useful to provide a more subtle distinction, allowing other
+   specifications to be more exact in a consistent way.
+
+   The proposal is consistent with existing standard specifications.
+
+8.  Security Considerations
+
+   This document specifies a means to represent Dial Sequences, which
+   could include GSTN addresses and private codes sequences, like
+   Personal Identification Numbers, to access special services.  As
+   these text strings could be transmitted without encoding inside
+   protocols or applications services, this could allow unauthorized
+   people to gain access to these codes.  Users SHOULD be provided
+   methods to prevent this disclosure, like code encryption, or
+   masquerading techniques: out-of-band communication of authorization
+   information or use of encrypted data in special fields are the
+   available non-standard techniques.
+
+
+
+
+Allocchio                   Standards Track                     [Page 7]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+9.  Collected ABNF Syntax
+
+   In this section we provide a summary of ABNF specifications.
+
+      phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+      DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+
+      written-sep = ( "-" / "." )
+
+      pause = "p"
+
+      tonewait = "w"
+
+      gstn-phone = ( global-phone / local-phone )
+
+      global-phone = "+" 1*( DIGIT / written-sep )
+
+      local-phone =  [ exit-code ] dial-number
+
+      local-phone =/ exit-code [ dial-number ]
+
+      exit-code = phone-string
+
+      dial-number = phone-string
+
+      subaddr-string = phone-string
+
+      post-dial = phone-string
+
+10.  References
+
+10.1.  Normative References
+
+   [1] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT):
+       Access Devices Dual Tone Multi Frequency (DTMF) sender for
+       acoustical coupling to the microphone of a handset telephone
+       (March 1995).
+
+   [2] ITU E.164 - The International Public Telecommunication Numbering
+       Plan E.164/I.331 (May 1997).
+
+   [3] Crocker, D. Ed. and P. Overell, "Augmented BNF for Syntax
+       Specifications: ABNF", RFC 2234, November 1997.
+
+   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Allocchio                   Standards Track                     [Page 8]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+   [5] ITU T.33 - Facsimile routing utilizing the subaddress;
+       recommendation T.33 (July, 1996).
+
+10.2.  Informative References
+
+   [6] Allocchio, C., "Minimal GSTN address format in Internet Mail",
+       RFC 3191, October 2001.
+
+   [7] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC
+       3192, October 2001.
+
+   [8] Allocchio, C., "GSTN Address Element Extensions in E-mail
+       Services", RFC 2846, June 2000.
+
+   [9] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
+       2000.
+
+11.  Author's Address
+
+   Claudio Allocchio
+   GARR
+   c/o Sincrotrone Trieste
+   SS 14 Km 163.5 Basovizza
+   I 34012 Trieste
+   Italy
+
+   Phone: +39 040 3758523
+   Fax:   +39 040 3758565
+   X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
+   EMail: Claudio.Allocchio@garr.it
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 9]
+
+RFC 3601       Dial Sequences and GSTN / E.164 Addresses  September 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 10]
+