summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2846.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2846.txt')
-rw-r--r--doc/rfc/rfc2846.txt1963
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]
+