RFC 3192

RFC 3192: Minimal FAX address format in Internet Mail 📠💖

okay bestie, let's get into this one 🦋 it's RFC 3192, written by C. Allocchio of GARR-Italy in October 2001. it's a Standards Track doc, which means it's a real protocol spec and not just a vibe. it obsoletes RFC 2304 and updates RFC 2846 🫶 the whole thing is about Minimal FAX address format in Internet Mail. yes, faxes in email, we're doing it 📠✨

Status of This Memo

this doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🌸 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so go wild 💅

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved. 🎀

Abstract

okay so this memo describes a simple way to encode Global Switched Telephone Network (GSTN) addresses of fax machines into the local-part of internet email addresses 📠🧚 the fax number just lives inside the email address, and it's giving clean

1. Introduction ✨

so, like every internet mail address, the left-hand side (the local-part) of an address made under this spec is not supposed to be read by anyone except the MTA named on the right-hand side (the domain) 👑 nobody else gets to peek

since the very first email-to-fax gateways showed up, implementors have been inventing their own ways to write a fax address as an email address 🙈 there were a few goals behind it, like letting an email user send and receive faxes from their inbox, and maybe making a "fax over email" service that could cut GSTN long-distance costs while still using the email infrastructure we already have 💜

this memo describes the MINIMAL addressing method, plus standard extensions for putting FAX addresses into email addresses, as required in reference [13] 🌈 the reverse problem, letting someone with a plain numeric-only fax machine reach the email transport service, is not covered here. not our problem today bestie 💅

the IANA forms used to register the standard elements defined here are in the "IANA Considerations" chapter (section 7 of this document) 🎀

all implementations that support the FAX over email address format MUST support this minimal specification 👑

1.1. Terminology and Syntax conventions

in this doc, the formal definitions are written in ABNF syntax, as defined in [7] 🧚 we also use some of the "CORE DEFINITIONS" from "APPENDIX A - CORE" of that document. the exact meaning of the capitalized words is defined in reference [6]. they are:

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

okay and here are the new terms this doc defines:

• I-fax device: an I-pstn device type [13] that can talk, directly or indirectly, with the traditional FAX over GSTN service 📠
• mta-I-fax: the Internet domain name that uniquely identifies an I-fax device on the Internet (see also mta-I-pstn in [13]) 🦋
• fax-email: the complete Internet email address structure that is used to carry a FAX address over the Internet email service (see also pstn-email in [13]) 💌

2. Minimal Fax address 📠

the minimal fax address in email was defined to stay consistent with reference [13], and it has two parts: the fax-mbox and an optional qualif-type1 element 💖

more precisely, the GSTN minimal address spec requires a unique service-selector for each specific application (section 2 in [13]) 👑

the "service-selector" for the fax service looks like this:

service-selector = "FAX"

the fax address syntax has a qualif-type1 element for supporting T.30/T.33 subaddresses (see section 2 of [13]) 🫶 using it is OPTIONAL, but compliant implementations MUST be able to support it and interpret it correctly when it's present. here's how it's defined:

qualif-type1 = "/" t33-sep "=" sub-addr

where

t33-sep = "T33S"

sub-addr = 1*( DIGIT )

so the minimal fax-in-email address is:

fax-address = fax-mbox [ "/T33S=" sub-addr ]

fax-mbox = "FAX=" global-phone

Notes: for a single subaddress, only numbers are allowed in <sub-addr>, which matches T.30, T.33, and this doc 🙈 T.30 and T.33 pad their field with SPACE, but this doc's <sub-addr> field doesn't need any padding. for multiple subaddresses, T.33 uses the "#" character to separate them. this doc only allows digits in the <sub-addr> field though, so for multiple <sub-addr> per <fax-mbox>, check out section 4.1 💅

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 = ( "-" / "." )

check section 2.1 in [13] for other important stuff about the global-phone element 🧚

2.2. Some examples of a minimal "fax-address"

here are some minimal fax-address examples 🌸

FAX=+3940226338

FAX=+12027653000/T33S=1387

FAX=+33-1-88335215

Note: these examples are just for illustration purposes, bestie 🎀

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 that identifies it on the Internet ✨ in internet mail, that's the Right Hand Side (RHS) of the address, meaning the part after the "@" sign. for this doc, we'll call it "mta-I-fax" 💜

mta-I-fax = domain

for "domain" strings used in SMTP transmissions, the string MUST conform to the requirements of those 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: domain names or domain literals are allowed in addresses in both the SMTP envelope and the message header fields 🌈

4. The fax-email 💌

the complete structure used to transfer a minimal FAX address over the Internet email transport system is called "fax-email" ✨ it's an email address that follows the "addr-spec" syntax from [2] and [3], with some structure refinements so the FAX number can be identified 🧚

fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax

Implementors' note: the optional "/" characters can show up after translations from other transport gateways (like some X.400 gateways) that included "/" 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 standards [2], [3] define exactly when the optional "quotes" characters around the entire local part (the part to the left of the "@" in the fax-email) MUST be added 🎀

4.1. Multiple subaddresses

some GSTN applications use multiple subaddresses, and T.33 subaddresses in the fax service are one of those cases 📠 in email practice, though, every recipient always gets their own unique email address. so if there are multiple T.33 subaddresses, using 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"

here are some minimal fax-email address examples 🌸

FAX=+3940226338@faxworld.org

FAX=+12027653000/T33S=1387@faxworld.org

/FAX=+33-1-88335215/@faxworld.org

Note: these examples are just for illustration purposes 🧚

8. Changes since RFC 2304 specification ✨

Okay bestie, there are no major or technical changes from RFC 2304 🫶 but here's where the updates and clarifications actually landed:

• Telephony systems don't stick to the old "single/few" Public Operator setup anymore 💅 so "PSTN - Public Switched Telephone Network" got a glow-up into "GSTN - Global Switched Telephone Network" 🌍. To stay consistent with the previous spec, the ABNF variable names were not changed.
• Section 7 "IANA Considerations" was added, along with IANA registration forms for the "FAX" "service-selector" and for the "T33S" "qualif-type1" elements 🎀.
• An explicit list of "new terms" with explanations was added to section 1.1 🧚.
• The case with multiple T.33 subaddresses got spelled out more clearly, so we know how to handle them (section 4.1) 🍓.
• In section 3, the language about "mta-I-fax" was updated to better explain its relationship with an Internet Mail address 🦋.
• In section 4, the quoting rules of the "fax-address" and how to actually use them were 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 swap ITU E.164 (1991) for ITU E.164 (1997) 🌸.

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).
• [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.

---

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. 💖