doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc2846.txt b/doc/rfc/rfc2846.txt
new file mode 100644
index 0000000..324f9b8
--- /dev/null
+++ b/doc/rfc/rfc2846.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                       C. Allocchio
+Request for Comments: 2846                                    GARR-Italy
+Category: Standards Track                                      June 2000
+
+
+           GSTN Address Element Extensions in E-mail Services
+
+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 (2000).  All Rights Reserved.
+
+Abstract
+
+   There are numerous applications where there is a need for interaction
+   between the GSTN addressing and Internet addressing.  This memo
+   defines a full syntax for one specific case, where there is a need to
+   represent GSTN addresses within Internet e-mail addresses. This full
+   syntax is a superset of a minimal syntax which has been defined in
+   [1].
+
+1. Introduction
+
+   The possible elements composing a "Global Switched Telephone Network
+   (GSTN) address in e-mail" (also known as the Public Switched
+   Telephone Network - PSTN) can vary from a minimum number up to a
+   really large and complex collection. As noted the minimal format and
+   general address syntax have been defined in [1], along with the
+   mechanism needed to define additional address elements. This memo
+   uses this extension mechanism to complete the syntax for representing
+   GSTN addresses within e-mail addresses and contains the IANA
+   registrations for all newly defined elements.
+
+   In particular, the following additional address elements shall be
+   defined:
+
+   -  the detailed definition of GSTN number formats, in order to cover
+      various alternative standard GSTN numbering schemes, (i.e. gstn-
+      phone, sub-addr-spec and post-dial)
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 1]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   -  the message originator and/or recipient specification (pstn-
+      recipient)
+
+   GSTN addresses in e-mail MAY contain additional elements defined and
+   registered in other specifications (see for example "T33S" element in
+   [2]), but they MUST use definitions contained in this memo for those
+   elements specified here.
+
+   In particular, "service-selector" names and "qualif-type1" elements
+   MUST be registered with IANA, and published within the "ASSIGNED
+   NUMBERS" document. This provides a standard mechanism for extending
+   the element sets and should avoid unnecessary duplication. IANA
+   Registration form templates for the purpouse of registering new
+   elements are provided in Appendix B. In addition the IANA
+   consideration section of this document defines the procedures
+   required to proceed with new registrations.
+
+   A collection of forms for already defined "service-selector" and
+   "qualif-type1" elements is listed in appendix C and appendix D
+   respectively.
+
+   In particular, efforts have been made to maintain compatibility with
+   elements defined in existing e-mail gateway services and standard
+   specifications. For example, to the extent possible, compatibility
+   has been maintained with the MIXER [3] gateways specifications.
+
+1.1 Relationship with Internet addressing other than e-mail
+
+   Even if in this memo we focus on e-mail addresses, a number of
+   elements defined in this specification can also be used for other
+   specifications dealing with embedding GSTN addresses into other
+   addresses: for example there is some work in progress about URLs
+   specification which adopts similar definitions, with slight changes
+   in the global syntax due to specific URL format.
+
+1.2 Terminology and Syntax conventions
+
+   In this document the formal definitions are described using ABNF
+   syntax, as defined into [4]. We will also use some of the "CORE
+   DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The
+   exact meaning of the capitalised words
+
+   "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED",  "MAY", "OPTIONAL"
+
+   is defined in reference [5].
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 2]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+2. GSTN extended number and pstn-mbox extended format
+
+   In reference [1], section 2, the minimal definition of pstn-mbox
+   includes the global-phone element, and further details are defined in
+   [1] section 2.1.
+
+   However other non global-phone numbering schemes are also possible.
+   Thus, the minimal set syntax defined in [1] shall be extended to
+   enable support for local-phone elements. Therefore, the gstn-phone
+   format is defined as follows:
+
+      gstn-phone = ( global-phone / local-phone )
+
+   The complexity of the GSTN system includes also the optional use of
+   subaddresses and post dialling sequences. As a consequence, there is
+   a need to extend the definition of pstn-mbox per [1] to include
+   support for both the minimal set definition and an extended syntax.
+
+   The expanded definition of pstn-mbox is as follows:
+
+      pstn-mbox = service-selector "=" global-phone
+
+      pstn-mbox =/ service-selector "=" gstn-phone
+                   [ sub-addr-spec ] [post-sep post-dial]
+
+   NOTE: see section 4 in the event multiple "sub-addr-spec" elements
+   per pstn-mbox need to be specified.
+
+2.1 The local-phone syntax
+
+   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 follows:
+
+      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...
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 3]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      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...
+
+   Note:
+      the "+" character is reserved for use in global-phone addresses
+      per [7] and MUST NOT be used as the starting character in a
+      local-phone string.
+
+      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 [6]
+                     ; 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"
+
+   The written-sep element is defined in [1], section 2.1.
+
+   Note:
+      "pause" and "tonewait" character interpretation in local-phone
+      numbers depends on the specific MTA implementation. Thus its exact
+      meaning is not defined here. Both "pause" and "tonewait" are case
+      insensitive.
+
+   Important Note:
+      A local-phone specification is a sequence which should be used
+      only by the destination  MTA specified by mta-I-pstn (see [1],
+      section 3). Per [12], other MTAs should transfer the message
+      without modifying the LHS.
+
+2.2 The sub-addr-spec element
+
+   In GSTN service there are cases where a sub-addr-spec is required to
+   specify the final destination. In particular there are ISDN
+   subaddresses [7], which apply for various  services, whereas other
+   subaddress types may be service specific (see the fax service T.33
+   subaddress [8], [2]).
+
+
+
+
+Allocchio                   Standards Track                     [Page 4]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Within actual telephone operations there may be cases where different
+   types of subaddresses are used as part of a single complete address.
+   Therefore, the sub-addr-spec syntax definition which follows defines
+   the subaddress element for the context of ISDN use; the T.33
+   subaddress element is defined in [2], section 2.
+
+   The definition of sub-addr-spec is:
+
+      sub-addr-spec = [ isdn-sep isub-addr ]
+
+   In detail:
+
+      isdn-sep = "/ISUB="
+                 ; note that "/ISUB=" is case INSENSITIVE
+
+      isub-addr = 1*( DIGIT )
+
+      isub-addr =/ 1*( DIGIT / written-sep )
+
+   The IANA registration form for sub-addr-spec is given in appendix D.2
+
+2.3 The post-sep and post-dial elements
+
+   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 handled using
+   "post-sep" and "post-dial" elements as defined below:
+
+      post-sep =  "/POSTD="
+                  ; note that "/POSTD=" is case INSENSITIVE
+
+      post-dial = phone-string
+
+   The IANA registration form for post-sep and post-dial are given in
+   appendix D.3
+
+3. The pstn-recipient
+
+   There are some application where it is valuable to supplement the
+   pstn-mbox element with additional details. Common examples include
+   the use of originator and/or recipient names and physical addresses,
+   particularly in the context of onramp and/or offramp gateways.
+
+   The optional pstn-recipient element provides support for such
+   details.
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 5]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   As an example, when an offramp fax gateway is involved, the
+   pstn-recipient element could be used to specify the intended
+   recipient on a fax cover page, and the fax cover page headers could
+   be qualified using the originator pstn-recipient information.
+
+   In the interest of a compact syntax, the pstn-recipient element may
+   be used to support both originator and recipient addresses. For all
+   cases within the ABNF definitions to follow, the elements labelled
+   with "recipient" may also be used for originator information.
+
+   The pstn-recipient is a sequence of qualif-type1 elements as defined
+   below:
+
+      pstn-recipient = [ recipient-name ]
+                       [ 1*( recipient-qualifier ) ]
+
+   As a consequence, the extended definition of pstn-address becomes:
+
+      pstn-address = pstn-mbox  [ qualif-type1 ]
+
+      pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
+
+
+   The definition for  qualif-type1 elements is contained in [1] section
+   2.
+
+3.1 The recipient-name
+
+   The recipient-name specifies the personal name of the originator
+   and/or recipient:
+
+      recipient-name = "/ATTN=" pers-name
+
+      pers-name = [ givenname "." ]
+                  [ initials "." ]
+                  surname
+
+   The following definitions come directly from the MIXER specification
+   [3]:
+
+      surname = printablestring
+
+      givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
+                    "," / "-" / "/" / ":" / "=" / "?" )
+
+      initials = 1*ALPHA
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 6]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Note:
+      the "initials" element can specify the middle initial which is
+      common in some countries; however it is also possible to support
+      multiple initials, which may be commonly used in other countries.
+      This allows the complete set of givennames initials in any
+      possible combination. See examples at section 5.2
+
+   It is essential to remember that the "pstn-address" element (in all
+   its components and extensions) MUST strictly follow the "quoting
+   rules" specified in the relevant e-mail standards [11], [12].
+
+   The IANA registration form for recipient-name is given in appendix
+   D.4.
+
+3.2 The extensible recipient-qualifier
+
+   The recipient-name is sometimes not enough to specify completely the
+   originator and/or recipient. An additional set of optional elements,
+   whose specific definition is in most cases application dependent, is
+   thus defined:
+
+      recipient-qualifier = ( qualif-type1 / qualif-type2 )
+
+   The recipient-qualifier is a qualif-type1 element, and contains a
+   qualif-type1 element in a recursive definition which allows an
+   extensible format. The purpouse of qualif-type2 element is to permit
+   additional extensibility for items which go beyond the scope of those
+   defined for use with the qualif-type1 element.
+
+   A series of qualif-type2 elements are defined below:
+
+      qualif-type2 = "/" qual2-label "=" string
+
+      qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR"
+                    "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"
+
+      string = PCHAR
+               ; note that printable characters are %x20-7E
+
+      printablestring = 1*( DIGIT / ALPHA / SP /
+                            "'" / "(" / ")" / "+" / "," / "-" /
+                            "." / "/" / ":" / "=" / "?" )
+                        ; this definition comes from ITU F.401 [9]
+                        ; and MIXER [3]
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 7]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Table 1 includes short definition of qual2-label fields:
+
+                        Table 1 - qual2-label
+
+   qual2-label  Description
+   -----------------------------------------------------------------
+     "ORG"      Organization Name for Physical Delivery (example: ACME
+                Inc)
+
+     "OFNO"     Office Number for physical delivery (example: BLD2-44)
+
+     "OFNA"     Office Name for physical delivery (example: Sales)
+
+      "STR"     Street address for physical delivery (example:
+                45, Main Street)
+
+     "ADDR"     Unformatted postal address for physical delivery
+                (example: HWY 14, Km 94.5 - Loc. Redhill)
+
+     "ADDU"     Unique postal name for physical delivery (example:
+                ACMETELEX)
+
+     "ADDL"     Local postal attributes for physical delivery (example:
+                Entrance 3, 3rd floor, Suite 296)
+
+      "POB"     Post Office Box for physical delivery
+
+      "ZIP"     Postal ZIP code for physical delivery
+
+       "CO"     Country Name for physical delivery
+   -----------------------------------------------------------------
+
+   One or a combination of some of the above elements is usually enough
+   to exactly specify the originator and/or recipient of the message.
+   The use of a large number of these elements could in fact create a
+   very long recipient-qualifier. Thus, only the strictly needed
+   elements SHOULD be used. The maximum total length of the pstn-email
+   MUST in fact not exceed the limits specified in the relevant e-mail
+   standards [11] [12].
+
+   IMPORTANT NOTE: Although the meaning of the above elements is derived
+   directly from similar elements available in F.401 specification [9],
+   the naming convention used in this document is explicitly different.
+   In this way a conflict is avoided with related X.400 addressing
+   rules.  Other specification which use the extension mechanism of this
+   document to define new qualif-type1 elements which overlap with F.401
+   are cautioned to create new labels which are different than those
+   used in F.401.
+
+
+
+Allocchio                   Standards Track                     [Page 8]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   The IANA registration form for these elements is given in appendix
+   D.5 to D.14.
+
+4. Multiple sub-addr-spec cases
+
+   There are some instances in GSTN applications where multiple
+   subaddresses are used: T.33 subaddresses in fax service are one of
+   these cases. In e-mail practice a separate and unique e-mail address
+   is always used for each recipient; as such, if multiple subaddresses
+   are present, the use of multiple "pstn-email" elements [1] is
+   REQUIRED.
+
+   Implementors' note:
+      The UA MAY accept multiple subaddress elements for the same
+      global-phone, but it MUST generate multiple "pstn-mbox" elements
+      when submitting the message to the MTA.
+
+5. Examples
+
+   In order to clarify the specification we present here a limited set
+   of examples. Many of the examples refer to the fax service, but also
+   additional possible services are included. Check also the examples in
+   [1] and [2] for additional information. Please note that all the
+   examples are for illustration purpouses, only.
+
+5.1 pstn-mbox examples
+
+   A pstn-mbox address in Italy for the fax service, dialled from
+   U.S.A., using local-phone, without sub-addr-spec and without
+   written-sep:
+
+      FAX=0103940226338
+
+   A pstn-mbox address in Germany for an hypothetical XYZ service, using
+   global-phone, with ISDN sub-addr-spec 1234 and written-sep ".":
+
+      XYZ=+49.81.7856345/ISUB=1234
+
+   A pstn-mbox address in U.S.A. for fax service, using global-phone,
+   with T.33 sub-addr-spec 8745, with written-sep "-" and post-dial
+   sequence p1w7005393w373
+
+      FAX=+1-202-455-7622/T33S=8745/PostD=p1w7005393w373
+
+   A pstn-mbox address in Italy for fax service, using local-phone,
+   dialed from an MTA in Germany, (international access code "00", with
+   ISDN subaddress 9823, with T.33 subaddress "4312" and without pause
+   or written-sep:
+
+
+
+Allocchio                   Standards Track                     [Page 9]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      FAX=003940226338/Isub=9823/T33S=4312
+
+   The same pstn-mbox address in Italy, using local-phone dialed from an
+   MTA in Italy (long distance call), with long distant access "0", with
+   exit-code "9", T.33 subaddress "4312", pause "p" and written-sep ".":
+
+      FAX=9p040p22.63.38/t33s=4312
+
+   A pstn-mbox address in North America for hypothetical service XYZ,
+   using global-phone, without sub-addr-spec and written-sep "-" and
+   ".":
+
+      XYZ=+1.202.344-5723
+
+   A pstn-mbox address for fax service in France, using local-phone
+   dialed from an MTA in France (long distance call), with exit-code
+   "0", T.33 subaddress "3345" and pause "p":
+
+      FAX=0p0134782289/T33s=3345
+
+   A pstn-mbox address for fax service in North America, using local-
+   phone, without sub-addr-spec, without local-number, using only post-
+   dial sequences to reach numbers stored in a locally defined short-
+   dial numbers database, where 6743 is an access password, and 99p51 is
+   the sequence to access the local short-dial number:
+
+      FAX=/postd=w6743w99p51
+
+5.2 pstn-recipient examples
+
+   Here are a number of pstn-recipient examples. Please note that pstn-
+   recipient is just an optional element, and thus a pstn-mbox element
+   also is required in a pstn-address.
+
+   A pstn-recipient using only recipient-name, with givenname initials
+   and surname:
+
+      /ATTN=Tom.J.Smiths
+
+   A pstn-recipient using only recipient-name, with givenname, a
+   complete set of initials (including the first name initial "C") and
+   surname (where the "real life" givennames are "Carlo Maria Luis
+   Santo" and the surname is "Nascimento"):
+
+      /ATTN=Carlo.CMLS.Nascimento
+
+   A pstn-recipient using only recipient-name, with givenname and
+   surname:
+
+
+
+Allocchio                   Standards Track                    [Page 10]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      /ATTN=Mark.Collins
+
+   A pstn-recipient using only recipient-name, with surname only:
+
+      /ATTN=Smiths
+
+   A pstn-recipient using recipient-name, and one recipient-qualifier
+   element:
+
+      /ATTN=J.Smiths/OFNA=Quaility-control
+
+   A pstn-recipient using two recipient-qualifier extension, only:
+
+      /OFNO=T2-33A/OFNA=Quality-Ccontrol
+
+   A fax-recipient using some recipient-qualifier for physical delivery:
+
+      /STR=45, Main.Street/OFNA=Sales.dept
+
+5.3 pstn-address examples
+
+   Some pstn-address examples, obtained combining elements from previous
+   examples. There are complete addresses which can be used as "local
+   part" (LHS) element of an e-mail address.
+
+   Without optional pstn-recipient (fax service):
+
+      FAX=+12023445723
+
+   With pstn-recipient (XYZ service):
+
+      XYZ=+3940226338/ATTN=Mark.Collins
+
+   With pstn-recipient made of two recipient-qualifier extensions (fax
+   service):
+
+      FAX=9p040p22.63.38/t33s=4312/ofno=T2-33A/OFNA=Q-C
+
+5.4 pstn-email examples
+
+   Here are the same addresses as before, where "faxgw" is the
+   mta-I-pstn field for the fax service.
+
+      FAX=+12023445723@faxgw
+
+      FAX=+39-40-226338/ATTN=Mark.Collins@faxgw
+
+      FAX=9p040p226338/T33S=4312/OFNO=T2-33A/OFNA=Q-C@faxgw
+
+
+
+Allocchio                   Standards Track                    [Page 11]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      FAX=+39040226338/ATTN=Mark.Collins/@faxgw
+
+   NOTE: the optional "/" in front for the "@" sign can be generated by
+   gateways to other services, like MIXER [3].
+
+5.5 A complete SMTP transaction example:
+
+   Here is an example of complete SMTP transaction.
+
+   S: <listening on SMTP port>
+   C: <opens connection to SMTP port>
+   S: 220 foo.domain.com ESMTP service ready
+   C: EHLO pc.mailfax.com
+   S: 250 foo.domain.com says hello
+   C: MAIL FROM:<tom@mailfax.com>
+   S: 250 <tom@mailfax.com> Sender ok
+   C: RCPT TO:<FAX=+3940226338@foo.mailfax.com>
+   S: 250 <FAX=+3940226338> recipient ok
+   C: DATA
+   S: 354 Enter your data
+   C: From: Thomas Blake <tom@mailfax.com>
+   C: To: Jim Burton <FAX=+3940226338@foo.mailfax.com>
+   C: Subject: Hello there
+   C: MIME-version: 1.0
+   C: Date: Mon, 01 Sep 1997 18:14:23 -0700
+   C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306
+   C:
+   C: This is a MIME message. It contains a
+   C: TIFF fax bodypart
+   C:
+   C: --16820115-1435684603#2306
+   C: Content-Type: image/TIFF
+   C: Content-Transfer-Encoding: BASE64
+   C: Content-Description: FAX
+   C:
+   C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA
+   C: 87AASS2999499ASDANASDF0000ASDFASDFNANN
+   C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0
+   C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8==
+   C: --16820115-1435684603#2306--
+   C: .
+   S: 250 Okay
+   C: QUIT
+   S: 221 Goodbye
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 12]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+6. Conclusion
+
+   This proposal creates a standard set of extensions for GSTN
+   addresses, enriching the existing minimal specification [1]. The
+   proposal is consistent with existing e-mail standards, but allows a
+   more detailed GSTN address specification, including per originator
+   and/or recipient specific elements. The IANA registration mechanism
+   to permit the addition of new services and qualifiers using the GSTN
+   addresses is also provided.
+
+7. Security Considerations
+
+   This document specifies a means by which GSTN addresses and more can
+   be encoded into e-mail addresses. Since e-mail routing is determined
+   by Domain Name System (DNS) data, a successful attack to DNS could
+   disseminate tampered information, which causes e-mail messages to be
+   diverted via some MTA or Gateway where the security of the software
+   has been compromised.
+
+   There are several means by which an attacker might be able to deliver
+   incorrect mail routing information to a client. These include: (a)
+   compromise of a DNS server, (b) generating a counterfeit response to
+   a client's DNS query, (c) returning incorrect "additional
+   information" in response to an unrelated query. Clients SHOULD ensure
+   that mail routing are based only on authoritative answers. Once DNS
+   Security mechanisms [7] become more widely deployed, clients SHOULD
+   employ those mechanisms to verify the authenticity and integrity of
+   mail routing records.
+
+   Some GSTN service require dialing of private codes, like Personal
+   Identification Numbers, to dial a G3 fax recipient or to access
+   special services. As e-mail addresses are transmitted without
+   encoding over the MTAs transport service, this could allow
+   unauthorized people to gain access to these codes when used inside
+   local-phone. More over these codes might appear in some cases in the
+   originator and/or recipient addresses on cover pages delivered via
+   offramp gateways to G3 fax recipients. Senders 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 13]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+8. Appendix A: Collected ABNF Syntax
+
+   In this section we provide a summary of ABNF specifications defining
+   both the minimal [1] and the extended elements of pstn-address.
+
+      pstn-email =  ["/"] pstn-address ["/"] "@" mta-I-pstn
+
+      mta-I-pstn = domain
+
+      pstn-address = pstn-mbox  [ qualif-type1 ]
+
+      pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
+
+      pstn-mbox = service-selector "=" global-phone
+
+      pstn-mbox =/ service-selector "=" gstn-phone
+                   [ sub-addr-spec ] [post-sep post-dial]
+
+      service-selector = 1*( DIGIT / ALPHA / "-" )
+
+      qualif-type1 = "/" keyword "=" string
+
+      keyword = 1*( DIGIT / ALPHA / "-" )
+
+      string = PCHAR
+
+      gstn-phone = ( global-phone / local-phone )
+
+      global-phone = "+" 1*( DIGIT , written-sep )
+
+      local-phone = [ exit-code ] [ dial-number ]
+
+      exit-code = phone-string
+
+      dial-number = phone-string
+
+      phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+      DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+
+      written-sep = ( "-" / "." )
+
+      pause = "p"
+
+      tonewait = "w"
+
+      sub-addr-spec = [ isdn-sep isub-addr ]
+
+
+
+
+Allocchio                   Standards Track                    [Page 14]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      isdn-sep = "/ISUB="
+
+      isub-addr = 1*( DIGIT )
+
+      isub-addr =/ 1*( DIGIT / written-sep )
+
+      post-sep =  "/POSTD="
+
+      post-dial = phone-string
+
+      pstn-recipient = [ recipient-name ]
+                       [ 1*( recipient-qualifier ) ]
+
+      recipient-name = "/ATTN=" pers-name
+
+      pers-name = [ givenname "." ]
+                  [ initials "." ]
+                  surname
+
+      surname = printablestring
+
+      givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
+                    "," / "-" / "/" / ":" / "=" / "?" )
+
+      initials = 1*ALPHA
+
+      recipient-qualifier = ( qualif-type1 / qualif-type2 )
+
+      qualif-type2 = "/" qual2-label "=" string
+
+      qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR"
+                    "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"
+
+      printablestring = 1*( DIGIT / ALPHA / SP /
+                            "'" / "(" / ")" / "+" / "," / "-" /
+                            "." / "/" / ":" / "=" / "?" )
+
+10. Appendix B: IANA Considerations
+
+   As the service-selector and qualif-type1 elements values are
+   extensible ones, they MUST be registered with IANA.
+
+   To register a service-selector or a qualif-type1 element, the
+   registration form templates given in B.1 and B.2 MUST be used. Any
+   new registration MUST fulfill the "Specification Required" criterion,
+   as defined in RFC 2434, section 2 [13]:
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 15]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      "Specification Required - Values and their meaning MUST be
+       documented in an RFC or other permanent and readily available
+       reference, in sufficient detail so that interoperability
+       between independent implementations is possible."
+
+   IANA MUST NOT accept registrations which are not supplemented by a
+   Specification as defined above and which are not fully specified
+   according to the template forms given in B.1 and B.2. In case of need
+   for further consultation about accepting a new registration, IANA
+   SHOULD refer to the Application Area Director to be directed to the
+   appropriate "expert" individual or IETF Working Group.
+
+   After successful registration, IANA should publish the registered new
+   element in the appropriate on-line IANA WEB site, and include it into
+   the updates of the "Assigned Numbers" RFC series.
+
+   B.1: IANA Registration form template for new values of GSTN address
+   service-selector
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            service-selector specifier "foo"
+
+   service-selector name:
+
+      foo
+
+   Description of Use:
+
+      foo - ("foo" is a fictional new service-selector used in this
+      template as an example, it is to be replaced with the new value
+      being registered. Include a short description of the use of the
+      new value here. This MUST include reference to Standard Track RFCs
+      and eventually to other Standard Bodies documents for the complete
+      description;  the use of the value must be defined completely
+      enough for independent implementation).
+
+   Security Considerations:
+
+      (Any additional security considerations that may be introduced by
+      use of the new service-selector parameter should be defined here
+      or in the reference Standards Track RFCs)
+
+   Person & email address to contact for further information:
+
+      (fill in contact information)
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 16]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   INFORMATION TO THE SUBMITTER:
+
+   The accepted registrations will be listed in the "Assigned Numbers"
+   series of RFCs.  The information in the registration form is freely
+   distributable.
+
+   B.2: IANA Registration form template for new values of GSTN
+   address qualif-type1 keyword and value
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "bar"
+
+   qualif-type1 "keyword" name:
+
+      bar
+
+   qualif-type1 "value" ABNF definition:
+
+      abnf - ("abnf" MUST define the ABNF form of the qualif-type1 value.
+      The ABNF specification MUST be self-contained, using as basic
+      elements the tokens given in specification [4]. To avoid any
+      duplication (when appropriate), it MUST also use as building
+      non-basic tokens any already registered non-basic token from other
+      qualif-type1 elements, i.e. it MUST use the same non-basic token
+      name and then repeat its identical ABNF definition from basic
+      tokens; see appendix E for examples).
+
+   Description of Use:
+
+      bar - ("bar" is a fictional description for a new qualif-type1
+      element used in this template as an example. It is to be replaced
+      by the real description of qualif-type1 element being registered.
+      Include a short description of the use of the new qualif-type1
+      here. This MUST include reference to Standards Track RFCs and
+      eventually to other Standard Bodies documents for the complete
+      description; the use of the value MUST be defined completely
+      enough for independent implementation.)
+
+   Use Restriction:
+
+      (If the new qualif-type1 elements is meaningful only for a
+      specific set of service-element, you MUST specify here the list of
+      allowed service-element types. If there is no restriction, then
+      specify the keyword "none")
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 17]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Security Considerations:
+
+      (Any additional security considerations that may be introduced by
+      use of the new service-selector parameter should be defined here
+      or in the reference Standards Track RFCs)
+
+   Person & email address to contact for further information:
+
+      (fill in contact information)
+
+   INFORMATION TO THE SUBMITTER:
+
+   The accepted registrations will be listed in the "Assigned Numbers"
+   series of RFCs.  The information in the registration form is freely
+   distributable.
+
+11. Appendix C: IANA Registration form for new value of GSTN
+    address service-selector "FAX"
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            service-selector specifier "FAX"
+
+   service-selector name:
+
+      FAX
+
+   Description of Use:
+
+      FAX - specify that the GSTN address refers either to an
+      Internet Fax device, or an onramp/offramp Fax gateway.
+
+      For a complete description refer to RFC 2304 and RFC 2303
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2304.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 18]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+12. Appendix D: IANA Registration forms for new values of GSTN
+       address qualit-type1 keyword and value
+
+   D.1 - T33S
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "T33S"
+
+   qualif-type1 "keyword" name:
+
+      T33S
+
+   qualif-type1 "value" ABNF definition:
+
+      sub-addr = 1*( DIGIT )
+
+   Description of Use:
+
+      T33S is used to specify the numeric only optional fax sub-address
+      element described in "ITU T.33 - Facsimile routing utilizing the
+      subaddress; recommendation T.33 (July, 1996)". Further detailed
+      description is available in RFC 2304.
+
+   Use Restriction:
+
+      The use of "T33S" is restricted to "FAX" service-selector, is it
+      has no meaning outside the fax service.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2304.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+
+
+
+Allocchio                   Standards Track                    [Page 19]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.2 - ISUB
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ISUB"
+
+   qualif-type1 "keyword" name:
+
+      ISUB
+
+   qualif-type1 "value" ABNF definition:
+
+      isub-addr = 1*( DIGIT )
+
+      isub-addr =/ 1*( DIGIT / written-sep )
+
+      written-sep = ( "-" / "." )
+
+   Description of Use:
+
+      "ISUB" is used to specify the optional ISDN sub-address elements used
+      in ISDN service to reach specific objects on the ISDN service. It can
+      eventually embed written separator elements for the only scope to
+      enhance human readability. See RFC 2846 for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 20]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.3 - POSTD
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "POSTD"
+
+   qualif-type1 "keyword" name:
+
+      POSTD
+
+   qualif-type1 "value" ABNF definition:
+
+      phone-string = 1*( DTMF / pause / tonewait / written-sep )
+
+      DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
+
+      pause = "p"
+
+      tonewait = "w"
+
+      written-sep = ( "-" / "." )
+
+   Description of Use:
+
+      POSTD is the optional further dialling sequence needed to access
+      additional services (for example a menu' driven interface)
+      available after the service site has been accessed using
+      gstn-phone. See RFC 2846 for further details.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 21]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.4 - ATTN
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ATTN"
+
+   qualif-type1 "keyword" name:
+
+      ATTN
+
+   qualif-type1 "value" ABNF definition:
+
+      pers-name = [ givenname "." ] [ initials "." ] surname
+
+      surname = printablestring
+
+      givenname = 1*( DIGIT /  ALPHA / SP / "'" / "+" /
+                    "," / "-" / "/" / ":" / "=" / "?" )
+
+      initials = 1*ALPHA
+
+      printablestring = 1*( DIGIT / ALPHA / SP /
+                            "'" / "(" / ")" / "+" / "," / "-" /
+                            "." / "/" / ":" / "=" / "?" )
+
+
+
+
+Allocchio                   Standards Track                    [Page 22]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Description of Use:
+
+      To specify the personal name of the individual intended as the
+      originator or the recipient of the message. See RFC 2846 for
+      further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.5 - ORG
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ORG"
+
+   qualif-type1 "keyword" name:
+
+      ORG
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Organization Name (example: ACME Inc.) See RFC 2846
+      for further details.
+
+
+
+
+Allocchio                   Standards Track                    [Page 23]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.6 - OFNO
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "OFNO"
+
+   qualif-type1 "keyword" name:
+
+      OFNO
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Office Number (example: BLD2-44) See RFC 2846
+      for further details.
+
+   Use Restriction:
+
+      none.
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 24]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.7 - OFNA
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "OFNA"
+
+   qualif-type1 "keyword" name:
+
+      OFNA
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Office Name (example: Sales) See RFC 2846
+      for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 25]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.8 - STR
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "STR"
+
+   qualif-type1 "keyword" name:
+
+      STR
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Street Address (example: 45, Main Street).
+      See RFC 2846 for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 26]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.9 - ADDR
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ADDR"
+
+   qualif-type1 "keyword" name:
+
+      ADDR
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Unformatted Postal Address (example: HWY 14,
+      Km 94.5 - Loc. Redhill). See RFC 2846 for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 27]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.10 - ADDU
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ADDU"
+
+   qualif-type1 "keyword" name:
+
+      ADDU
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Unique Postal Name (example: ACMETELEX). See
+      RFC 2846 for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 28]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.11 - ADDL
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ADDL"
+
+   qualif-type1 "keyword" name:
+
+      ADDL
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Local Postal Attributes (example: Entrance 3,
+      3rd floor, Suite 296). See RFC 2846 for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 29]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.12 - POB
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "POB"
+
+   qualif-type1 "keyword" name:
+
+      POB
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Post Office Box (example: CP 1374). See RFC 2846
+      for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 30]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.13 - ZIP
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "ZIP"
+
+   qualif-type1 "keyword" name:
+
+      ZIP
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify Postal ZIP code (example: I 34012). See RFC 2846
+      for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 31]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+   D.14 - CO
+
+   To: IANA@isi.edu
+   Subject: Registration of new values for the GSTN address
+            qualif-type1 element "CO"
+
+   qualif-type1 "keyword" name:
+
+      CO
+
+   qualif-type1 "value" ABNF definition:
+
+      string = PCHAR
+
+   Description of Use:
+
+      To specify the Country Name (example: Belgium) See RFC 2846
+      for further details.
+
+   Use Restriction:
+
+      none.
+
+   Security Considerations:
+
+      See the Security Consideration section of RFC 2846.
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 32]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   Person & email address to contact for further information:
+
+      Claudio Allocchio
+      INFN-GARR
+      c/o Sincrotrone Trieste
+      SS 14 Km 163.5 Basovizza
+      I 34012 Trieste
+      Italy
+
+      RFC822: Claudio.Allocchio@elettra.trieste.it
+      X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+              S=Allocchio;G=Claudio;
+      Phone:  +39 040 3758523
+      Fax:    +39 040 3758565
+
+13. Author's Address
+
+   Claudio Allocchio
+   INFN-GARR
+   c/o Sincrotrone Trieste
+   SS 14 Km 163.5 Basovizza
+   I 34012 Trieste
+   Italy
+
+   RFC822: Claudio.Allocchio@elettra.trieste.it
+   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+           S=Allocchio;G=Claudio;
+   Phone:  +39 040 3758523
+   Fax:    +39 040 3758565
+
+14. References
+
+   [1]  Allocchio, C., "Minimal PSTN address format in Internet Mail",
+        RFC 2303, March 1998.
+
+   [2]  Allocchio, C., "Minimal FAX address format in Internet Mail",
+        RFC 2304, March 1998.
+
+   [3]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+        between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+   [4]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications", RFC 2234, November 1997.
+
+   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 33]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+   [6]  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)
+
+   [7]  ITU E.164 - The International Public Telecommunication Numbering
+        Plan E.164/I.331 (May 1997)
+
+   [8]  ITU T.33 - Facsimile routing utilizing the subaddress;
+        recommendation T.33 (July, 1996)
+
+   [9]  ITU F.401 - Message Handling Services: Naming and Addressing for
+        Public Massage Handling Service; recommendation F.401 (August
+        1992)
+
+   [10] ITU F.423 - Message Handling Services: Intercommunication
+        Between the Interpersonal Messaging Service and the Telefax
+        Service; recommendation F.423 (August 1992)
+
+   [11] Crocker, D., "Standard for the format of ARPA Internet text
+        messages", STD 11, RFC 822, August 1982.
+
+   [12] Braden, R., "Requirements for Internet hosts - application and
+        support", STD 3, RFC 1123, October 1989.
+
+   [13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 34]
+
+RFC 2846       GSTN Address Extensions in E-mail Services      June 2000
+
+
+15. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  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 assigns.
+
+   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 35]
+