diff options
Diffstat (limited to 'doc/rfc/rfc3192.txt')
-rw-r--r-- | doc/rfc/rfc3192.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc3192.txt b/doc/rfc/rfc3192.txt new file mode 100644 index 0000000..b898d8d --- /dev/null +++ b/doc/rfc/rfc3192.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 3192 GARR-Italy +Obsoletes: 2304 October 2001 +Updates: 2846 +Category: Standards Track + + + Minimal FAX 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 of facsimile devices in the + local-part of Internet email addresses. + +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 the MTA that is named on the right-hand-side + (domain). + + Since the very first e-mail to fax gateway objects appeared, a number + of different methods to specify a fax 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 send and + receive faxes from his/her e-mail interface, to allow some kind of + "fax over e-mail service" transport (possibly reducing the costs of + GSTN long distance transmissions) while using the existing e-mail + infrastructure. + + This memo describes the MINIMAL addressing method and standard + extensions to encode FAX addresses into e-mail addresses, as required + in reference [13]. The opposite problem, i.e., to allow a + traditional numeric-only fax device user to access the e-mail + transport service, is not discussed here. + + + +Allocchio Standards Track [Page 1] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + These IANA forms used to register the standard elements defined here + are given in the "IANA Considerations" chapter (section 7 of this + document). + + All implementations supporting FAX over e-mail address format MUST + support this minimal specification. + +1.1 Terminology and Syntax conventions + + In this document the formal definitions are described using ABNF + syntax, as defined into [7]. We will also use 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-fax device: + an I-pstn device type [13] which is able to communicate either + directly or indirectly with the traditional FAX over GSTN + service; + + mta-I-fax: + the Internet domain name which identifies uniquely an I-fax + device over the Internet (see also mta-I-pstn in [13]); + + fax-email: + the complete Internet e-mail address structure which is used to + transport a FAX address over the Internet e-mail service (see + also pstn-email in [13]). + +2. Minimal Fax address + + The minimal fax address within e-mail has been defined for + consistency with reference [13] and it contains two elements: the + fax-mbox and an optional qualif-type1 element. + + More precisely the GSTN minimal address specification requires the + use of a unique service-selector for each specific application + (section 2 in [13]). + + The "service-selector" defined for the fax service is as follows: + + service-selector = "FAX" + + + +Allocchio Standards Track [Page 2] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + In the syntax for the fax address a qualif-type1 element has been + defined for support of T.30/T.33 subaddresses (see section 2 of + [13]). The use of this element is OPTIONAL, but compliant + implementations MUST be able to support and correctly interpret it + when present. Its definition is as follows: + + qualif-type1 = "/" t33-sep "=" sub-addr + + where + + t33-sep = "T33S" + + sub-addr = 1*( DIGIT ) + + Thus, the minimal specification of a fax in e-mail address is: + + fax-address = fax-mbox [ "/T33S=" sub-addr ] + + fax-mbox = "FAX=" global-phone + + Notes: + + For the case of a single subaddress, only numbers are allowed in + <sub-addr> which is consistent with T.30, T.33, and this document. + While T.30 and T.33 use SPACE to pad its field, padding isn't + necessary in the <sub-addr> field defined by this document. + + For the case of multiple subaddresses, T.33 specifies the "#" + character be used to specify multiple subaddreses. However, only + digits are permitted in the <sub-addr> field defined by this + document. Refer to section 4.1 in case multiple <sub-addr> per + per <fax-mbox> need to be specified. + + The Minimal supported syntax for global-phone (as described in + section 2.1 of reference [13]) is: + + global-phone = "+" 1*( DIGIT / written-sep ) + + written-sep = ( "-" / "." ) + + Refer to section 2.1 in [13] for other important considerations about + the global-phone element. + +2.2 Some examples of a minimal "fax-address" + + Some examples of minimal fax-address follows: + + + + + +Allocchio Standards Track [Page 3] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + FAX=+3940226338 + + FAX=+12027653000/T33S=1387 + + FAX=+33-1-88335215 + + Note: + + the examples shown are just for illustration purposes. + +3. The e-mail address of the I-fax device: mta-I-fax + + An "I-fax 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-fax" + + mta-I-fax = 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 fax-email + + The complete structure used to transfer a minimal FAX address over + the Internet e-mail transport system is called "fax-email". This + object is a an e-mail address which conforms to [2] and [3] + "addr-spec" syntax, with structure refinements which allows the FAX + number to be identified. + + fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax + + 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 + + + +Allocchio Standards Track [Page 4] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + 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 + fax-email) MUST be added. + +4.1 Multiple subaddresses + + 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 T.33 + subaddresses are present, the use of multiple "fax-email" elements is + REQUIRED. + + Implementors' note: + + The UA MAY accept multiple subaddress elements for the same + global-phone, but it MUST generate multiple "fax-mbox" elements + when submitting the message to the MTA. + +4.2 Some examples of minimal "fax-email" + + Some examples of minimal fax-email addresses follows: + + FAX=+3940226338@faxworld.org + + FAX=+12027653000/T33S=1387@faxworld.org + + /FAX=+33-1-88335215/@faxworld.org + + Note: + + the examples shown are just for illustration purposes. + +5. Conclusion + + This proposal creates a minimal standard encoding for FAX addresses + within the global e-mail transport system. The proposal is + consistent with existing e-mail standards. + +6. Security Considerations + + This document specifies a means by which FAX 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 5] + +RFC 3192 Minimal FAX 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 + + The IANA registration forms for "FAX" service-selector and "T33S" + qualif-type1 elements are defined here. These forms update the + previous registration forms defined in [15]. + +7.1 IANA Registration form for updated value of GSTN + address service-selector "FAX" + + To: IANA@iana.org + Subject: Registration of updated 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 3192 and RFC 3191. + + Security Considerations: + + See the Security Consideration section of RFC 3192. + + 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 6] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + 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 + +7.2 IANA Registration form for updated value of GSTN + address qualit-type1 keyword "T33S" and value + + To: IANA@iana.org + Subject: Registration of updated 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 3192. + + 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 3192. + + 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 7] + +RFC 3192 Minimal FAX address format in Internet Mail October 2001 + + + 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 + +8. Changes since RFC 2304 specification + + Although there are no major or technical changes from RFC 2304 + specification, this section briefly describes where updates and + clarifications were introduced: + + - 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. + + - section 7 "IANA Considerations" and the IANA registration forms + for the "FAX" "service-selector" and for the "T33S" "qualif-type1" + elements were added; + + - an explicit list of "new terms" with explanations was added to + section 1.1; + + - the case when multiple T.33 subaddresses are present was described + more explicitly in order to clarify how to handle them (section + 4.1); + + - in section 3 the language describing "mta-I-fax" was updated to + better describe its relationship with an Internet Mail address; + + - in section 4., the quoting rules of the "fax-address" and their + practical use was made explicit both in the definition of "fax- + email" and in the Implementors' note; + + - the Author's Address was updated; + + - the References list was updates to substitute ITU E.164 (1991) + with ITU E.164 (1997). + + + + + + + + + + + +Allocchio Standards Track [Page 8] + +RFC 3192 Minimal FAX 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 9] + +RFC 3192 Minimal FAX 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 GSTN address format in Internet Mail", + RFC 3191, 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 10] + +RFC 3192 Minimal FAX 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 11] + |