diff options
Diffstat (limited to 'doc/rfc/rfc3191.txt')
| -rw-r--r-- | doc/rfc/rfc3191.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3191.txt b/doc/rfc/rfc3191.txt new file mode 100644 index 0000000..e2e9949 --- /dev/null +++ b/doc/rfc/rfc3191.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 3191 GARR-Italy +Obsoletes: 2303 October 2001 +Updates: 2846 +Category: Standards Track + + + Minimal GSTN address format in Internet Mail + +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 (2001). All Rights Reserved. + +Abstract + + This memo describes a simple method of encoding Global Switched + Telephone Network (GSTN) addresses (commonly called "telephone + numbers") in the local-part of Internet email addresses, along with + an extension mechanism to allow encoding of additional standard + attributes needed for email gateways to GSTN-based services. + +1. Introduction + + As with all Internet mail addresses, the left-hand-side (local-part) + of an address generated according to this specification, is not to be + interpreted except by an MTA that handles messages for the domain + given in the right-hand-side. + + Since the very first e-mail to GSTN services gateway appeared, a + number of different methods to specify a GSTN address as an e-mail + address have been used by implementors. Several objectives for this + methods have been identified, like to enable an e-mail user to access + GSTN services from his/her e-mail interface, to allow some kind of + "GSTN over e-mail service" transport (possibly reducing the costs of + GSTN long distance transmissions) while using the existing e-mail + infrastructure. + + + + + + + +Allocchio Standards Track [Page 1] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + This memo describes the MINIMAL addressing method to encode GSTN + addresses into e-mail addresses and the standard extension mechanism + to allow definition of further standard elements. The opposite + problem, i.e., to allow a traditional numeric-only GSTN device user + to access the e-mail transport service, is not discussed here. + + The IANA registration templates which MUST be used to register any + standard element defined according to this specification are given in + the "IANA Considerations" chapter (section 7 of this document). + + All implementations supporting this GSTN over e-mail service MUST + support as a minimum the specification described in this document. + The generic complex case of converting the entirety of GTSN + addressing into e-mail is out of scope in this minimal specification. + +1.1 Terminology and Syntax conventions + + In this document the formal definitions are described using ABNF + syntax, as defined into [7]. This memo also uses some of the "CORE + DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The + exact meaning of the capitalized words + + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" + + is defined in reference [6]. + + In this document the following new terms are also defined: + + I-pstn device: + a device which has an Internet domain name and it is able to + communicate either directly or indirectly with the GSTN + network; + + mta-I-pstn: + the Internet domain name which identifies uniquely an I-pstn + device over the Internet; + + pstn-email: + the complete Internet e-mail address structure which is used to + transport a GSTN address over the Internet e-mail service. + +2. Minimal GSTN address + + The minimal specification of a GSTN address within an e-mail address + is as follows: + + + + + +Allocchio Standards Track [Page 2] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + pstn-address = pstn-mbox [ qualif-type1 ] + + pstn-mbox = service-selector "=" global-phone + + service-selector = 1*( DIGIT / ALPHA / "-" ) + ; note that SP (space) is not allowed in + ; service-selector. + ; service-selector MUST be handled as a case + ; INSENSITIVE string by implementations. + + Other specifications adopting the "pstn-address" definition MUST + define and register with IANA a unique case insensitive + "service-selector" element to identify the specific messaging service + involved. + + These specifications and registrations MUST also define which minimal + "qualif-type1" extensions, if any, MUST be supported for the + specified messaging service. + + Implementations confirming to this minimal requirements specification + are allowed to ignore any other non-minimal extensions address + element which is present in the "pstn-address". However, conforming + implementations MUST preserve all "qualif-type1" address elements + they receive. + + The generic "qualif-type1" element is defined as: + + qualif-type1 = "/" keyword "=" string + + keyword = 1*( DIGIT / ALPHA / "-" ) + ; note that SP (space) is not allowed in keyword + + string = PCHAR + ; note that printable characters are %x20-7E + + As such, all "pstn-address" extension elements MUST be defined in the + "qualif-type1" form at the time of registration with IANA. + +2.1 Minimal "global-phone" definition + + The purpose of global-phone element is to represent standard E.164 + numeric addresses [10] within a syntax for electronic mail addressing + that is compliant with standard e-mail specifications given in [1] + and [2]. + + + + + + + +Allocchio Standards Track [Page 3] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + The minimal supported syntax for global-phone element is as follows: + + global-phone = "+" 1*( DIGIT / written-sep ) + + written-sep = ( "-" / "." ) + + The use of other dialing schemes for GSTN numbers (like private + numbering plans or local dialing conventions) is also allowed. + However, this does not preclude nor remove the mandatory requirement + for support to the "global-phone" syntax within the minimal GSTN + address format. + + Any other dialing schemes MUST NOT use the leading "+" defined here + between the "=" sign and the dialing string. The "+" sign is + strictly reserved for the standard "global-phone" syntax. + + Note: + + The specification of alternate dialing schemas is out of scope for + this minimal specification. + + This document also permits the use of written-sep elements in order + to improve human readability of GSTN e-mail addresses. The + written-sep are elements which can be placed between dial elements + such as digits etc. + + Implementors' note: + + Use of the written-sep elements is allowed, but not recommended + for transmission. Any occurrences of written-sep elements in a + pstn-mbox MUST be ignored by all conformant implementations. + +2.2 The minimal "pstn-address" examples + + Some examples of minimal pstn-address are: + + VOICE=+3940226338 + + FAX=+12027653000/T33S=6377 + + SMS=+33-1-88335215 + + Note: + + these examples are given as illustrations only; they do not + necessarily represent valid pstn-addresses. + + + + + +Allocchio Standards Track [Page 4] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + +3. The e-mail address of the I-pstn device: mta-I-pstn + + An "I-pstn device" has, among its characteristics, a unique Internet + domain name which identifies it on the Internet. Within Internet + mail, this is the Right Hand Side (RHS) part of the address, i.e., + the part on the right of the "@" sign. For purposes of this document + we will call this "mta-I-pstn" + + mta-I-pstn = domain + + For "domain" strings used in SMTP transmissions, the string MUST + conform to the requirements of that standards <domain> specifications + [1], [3]. For "domain" strings used in message content headers, the + string MUST conform to the requirements of the relevant standards + [2], [3]. + + Note: + + the use of "domain names" or "domain literals" is permitted in + addresses in both the SMTP envelope and message header fields. + +4. The pstn-email + + The complete structure used to transfer a minimal GSTN address over + the Internet e-mail transport system is called "pstn-email". This + object is a an e-mail address which conforms to [2] and [3] + "addr-spec" syntax, with structure refinements which allows the GSTN + number to be identified. + + pstn-email = ["""] ["/"] pstn-address ["/"] ["""] "@" mta-I-pstn + + Implementors' note: + + The optional "/" characters can result from translations from + other transport gateways (such as some X.400 gateways) which have + included the "/" as an optional element. Implementations MUST + accept the optional slashes but SHOULD NOT generate them. + Gateways are allowed to strip them off when converting to Internet + mail addressing. The relevant standard [2], [3] define exactly + when the optional "quotes" characters surrounding the entire local + part (i.e., the part on the left of the "@" character into the + pstn-email) MUST be added. + +4.1 Multiple subaddresses + + There are some instances in GSTN applications where multiple + subaddresses are used. On the other hand in e-mail practice a + separate and unique e-mail address is always used for each recipient. + + + +Allocchio Standards Track [Page 5] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + In the event a particular GSTN service requires multiple subaddresses + (in any form defined by the standard specification for that GSTN + service) that are associated with the same "pstn-mbox", then the use + of multiple "pstn-email" elements 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. + +4.2 Some examples of minimal "pstn-email" addresses + + Some examples of minimal pstn-email addresses follows: + + VOICE=+3940226338@worldvoice.com + + FAX=+1.202.7653000/T33S=6377@faxserv.org + + /SMS=+33-1-88335215/@telecom.com + + Note: + + these examples are given as illustrations only; they do not + necessarily represent valid pstn-addresses. + +5. Conclusions + + This proposal creates a minimal standard encoding for GSTN addresses + within the global e-mail transport system. It also defines the + standard extension mechanism to be used to introduce new elements for + GSTN addresses. + + The proposal is consistent with existing e-mail standards. Each + specific GSTN service using this proposal MUST define and register + with IANA its own "service-selector" specification and MUST define + and register the eventual other "qualif-type1" elements needed for + its specific application. An example of such an application is + contained in reference [13]. + +6. Security Considerations + + This document specifies a means by which GSTN addresses 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. + + + +Allocchio Standards Track [Page 6] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + 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 is based only on authoritative answers. + Once DNS Security mechanisms [5] become more widely deployed, clients + SHOULD employ those mechanisms to verify the authenticity and + integrity of mail routing records. + +7. IANA Considerations + + As the service-selector and qualif-type1 elements values are + extensible, they MUST be registered with IANA. + + To register a service-selector or a qualif-type1 element, the + registration form templates given in 7.1 and 7.2 MUST be used. Any + new registration MUST fulfill the "Specification Required" criteria, + as defined in RFC 2434, section 2 [16]: + + "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 7.1 and 7.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. + + This section (including 7.1 and 7.2) updates the ones contained in + [15]. + +7.1 IANA Registration form template for new values of GSTN + address service-selector + + To: IANA@iana.org + Subject: Registration of new values for the GSTN address + service-selector specifier "foo" + + + + + + +Allocchio Standards Track [Page 7] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + 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) + + 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. + +7.2 IANA Registration form template for new values of GSTN + address qualif-type1 keyword and value + + To: IANA@iana.org + 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 any already + + + + +Allocchio Standards Track [Page 8] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + 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. + + 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") + + 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. + +8. Changes from RFC 2303 specification + + Although there are no technical or major changes from RFC 2303 + specification, this section briefly describes where updates and + clarifications were introduced: + + + + + + + + +Allocchio Standards Track [Page 9] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + - considering the case that telephony systems do not conform any + more to the "single/few" Public Operator paradigm, the old + definition "PSTN - Public Switched Telephone Network" was changed + into the more adequate "GSTN - Global Switched Telephone Network" + one. However, in order to remain consistent with the previous + specification, the ABNF variables names were not changed. + + - it was made clear that "GSTN addresses" correspond, in common + language, to "telephone numbers" and that the "global-phone" is a + representation of E.164 numeric addresses; + + - an explicit list of "new terms" with explanations was added to + section 1.1; + + - the fact that any other specification adopting the "pstn-address" + definition MUST register with IANA the new "service-selector" and + "qualif-type1" elements was made explicit throughout the document; + the relevant mechanism to be used was added in section 7 "IANA + considerations" (including the IANA Registration form templates); + this is also consistent with RFC 2846; + + - in section 2.1 the use and meaning of "written-sep" was clarified; + + - in section 4., the quoting rules of the "pstn-address" and their + practical use was made explicit both in the definition of + pstn-email" and in the Implementors' note; + + - section 4.1 was updated to clarify how to generate "pstn-email" + when more than one subaddress is used; + + - the Author's Address was updated; + + - the References list was updated to include RFC 2846 and RFC 2434. + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 10] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + +9. Author's Address + + Claudio Allocchio + INFN-GARR + c/o Sincrotrone Trieste + SS 14 Km 163.5 Basovizza + I 34012 Trieste + Italy + + RFC2822: Claudio.Allocchio@garr.it + X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio; + Phone: +39 040 3758523 + Fax: +39 040 3758565 + +10. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, August 1982. + + [3] Braden, R., "Requirements for Internet hosts - application and + support", STD 3, RFC 1123, October 1989. + + [4] Malamud, C. and M. Rose, "Principles of Operation for the + TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC + 1528, October 1993. + + [5] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications", RFC 2234, November 1997. + + [8] ITU F.401 - Message Handling Services: Naming and Addressing for + Public Message Handling Service; recommendation F.401 (August + 1992). + + [9] ITU F.423 - Message Handling Services: Intercommunication + Between the Interpersonal Messaging Service and the Telefax + Service; recommendation F.423 (August 1992). + + [10] ITU E.164 - The International Public Telecommunication Numbering + Plan E.164/I.331 (May 1997). + + + +Allocchio Standards Track [Page 11] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + + [11] ITU T.33 - Facsimile routing utilizing the subaddress; + recommendation T.33 (July 1996). + + [12] 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). + + [13] Allocchio, C., "Minimal FAX address format in Internet Mail", + RFC 3192, October 2001. + + [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [15] Allocchio, C. "GSTN address element extensions in e-mail + services", RFC 2846, June 2000. + + [16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 12] + +RFC 3191 Minimal GSTN address format in Internet Mail October 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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 13] + |