From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2846.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc2846.txt (limited to 'doc/rfc/rfc2846.txt') 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: + C: + S: 220 foo.domain.com ESMTP service ready + C: EHLO pc.mailfax.com + S: 250 foo.domain.com says hello + C: MAIL FROM: + S: 250 Sender ok + C: RCPT TO: + S: 250 recipient ok + C: DATA + S: 354 Enter your data + C: From: Thomas Blake + C: To: Jim Burton + 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] + -- cgit v1.2.3