RFC 2303

Minimal PSTN address format in Internet Mail

📅 published March 1998, from ietf

Minimal PSTN address format in Internet Mail 💌

Network Working Group, Request for Comments: 2303 🎀 Author: C. Allocchio (GARR-Italy) 🦋 Category: Standards Track 👑 Date: March 1998 🌸 Obsoletes / Updates: nothing is listed in the title block 💅

Status of This Memo ✨

Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking everyone for discussion and suggestions for improvements 🫶. If you want the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed freely, no cap 💖.

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

IESG NOTE 📝

Here's the vibe: this memo describes a simple way to encode PSTN addresses in the local-part of Internet email addresses. It also has an extension mechanism so you can add extra standard attributes that email gateways need to reach PSTN-based services 🧚.

Also, same as with every Internet mail address, the left-hand side (local-part) of an address made under this spec is not to be interpreted by anyone except the MTA named on the right-hand side (domain). Hands off, bestie 🙈.

1. Introduction 🦋

Ever since the very first email-to-PSTN services gateway showed up, implementors have been inventing all kinds of ways to write a PSTN address as an email address 💅. Two big goals drove this:

  • letting an email user reach these services straight from their email interface 📬;
  • enabling a kind of "PSTN over email" transport 🚀, which cuts the cost of long distance PSTN calls by riding on the email infrastructure that already exists.

This memo is about the MINIMAL addressing method for encoding PSTN addresses into email addresses, plus the standard extension mechanism for defining more standard elements later 🎀. The other direction, letting a traditional numbers-only PSTN device user get onto the email transport service, is NOT discussed here, so don't look for it 🙈.

Every implementation that supports this PSTN over email service MUST support, as a minimum, the specification in this document 🔥. The full, generic case of converting all of PSTN addressing into email is out of scope for this minimal spec. There's work in progress on that, and a bunch of standard optional extensions are being defined too 💖.

The formal definitions here use ABNF syntax, as defined in [7] 🧚. We'll also borrow some of the "CORE DEFINITIONS" from "APPENDIX A - CORE" of that same document. The exact meaning of the capitalised keywords:

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

is defined in reference [6] ✨.

2. Minimal PSTN address 💌

Here's the minimal spec for a PSTN address in an email address 💅:

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.

Specs that adopt the "pstn-address" definition MUST define a unique, case insensitive "service-selector" element to identify the specific messaging service involved 🎀. They also MUST define which minimal "qualif-type1" extensions, if any, MUST be supported for that service 💖.

Implementations that conform to these minimal requirements are allowed to ignore any other non-minimal extension address elements that might show up in the "pstn-address" 🦋. But conforming implementations MUST preserve all "qualif-type1" address elements they receive, no exceptions 🫶.

The generic "qualif-type1" element is defined like this:

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

So honestly, every "pstn-address" extension element MUST be defined in the "qualif-type1" form 👑. No freelancing!

2.1 Minimal "global-phone" definition 📞

Here's the minimal syntax we support for global-phone 💅:

global-phone = "+" 1*( DIGIT , written-sep )

written-sep = ( "-" / "." )

Other dialling schemes for PSTN numbers (like private numbering plans or local dialling conventions) are also allowed ✨. That doesn't get rid of the minimal compulsory requirement to support the "global-phone" syntax above, though. It's still a must-have 🌈.

A non-"global-phone" dialling scheme MUST NOT use the leading "+" between the "=" sign and the dialling string 🚫. The "+" is strictly reserved for the standard "global-phone" syntax, so don't steal it, bestie 💀.

Note: Specs for these other dialling schemes are out of scope for this minimal spec 💜.

Users should be able to type in PSTN email addresses with separators between dial elements like digits, so that's why the syntax allows written-sep 🍓.

Implementors' note: Using the written-sep elements is allowed, but not recommended 🙈. Any written-sep elements in a pstn-mbox MUST be ignored by all conformant implementations. Also, User Agents SHOULD remove written-sep elements before submitting messages to the Message Transport System 🫶.

2.2 Some examples of a minimal "pstn-address" 🌸

VOICE=+3940226338

FAX=+12027653000/T33S=6377

SMS=+33-1-88335215

3. The e-mail address of the I-pstn device: mta-I-pstn 🧚

An "I-pstn device" has an email address. To be more exact, it has a name that lets a mail system find it on the global email system 🌍.

In Internet mail, that name is the Right Hand Side (RHS), meaning the part to the right of the "@" sign. We'll call it "mta-I-pstn" 💖:

mta-I-pstn = domain

For "domain" strings used in SMTP transmissions, the string MUST conform to the requirements of that standard's <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: In both cases, the standards let you use "domain names" or "domain literals" in addresses ✨.

4. The pstn-email 💌

The whole structure used to move a minimal PSTN address across the Internet email transport system is called "pstn-email" 🚀. It's an email address that follows the RFC822 [2] and RFC1123 [3] "addr-spec" syntax, plus a bit of extra structure so the PSTN number can be identified 🦋.

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

Implementors' note: The optional "/" characters can come from other mail transport services gateways, where they're optional too 🌸. Implementations MUST accept the optional slashes but SHOULD NOT generate them. Gateways are allowed to strip them off when converting to Internet mail addressing 🫶.

Just a reminder, though: the "pstn-address" element MUST strictly follow the "quoting rules" specified in the relevant standards [2], [3] 🔥.

4.1 Multiple subaddresses 📬

Sometimes a service needs multiple subaddresses (in any form the service's own standard defines), and they all have to go on the same "pstn-mbox". In that case, you use multiple "pstn-email" elements 💅.

Implementors' note: The UA could accept multiple subaddress elements for the same global-phone, but it must generate multiple "pstn-mbox" elements when passing the message to the MTA 🧚.

4.2 Some examples of "pstn-email" 💖

VOICE=+3940226338@worldvoice.com

FAX=+1.202.7653000/T33S=6377@faxserv.org

/SMS=+33-1-88335215/@telecom.com

Okay, the legal part is giving lawyer energy, but it's important so let's go 💅

Copyright (C) The Internet Society (1998). All Rights Reserved. 💖

You're totally allowed to copy this doc and share it with your people 🫶, and to make derivative works that comment on it, explain it, or help people implement it. You can prepare, copy, publish and distribute those, in whole or in part, without restriction of any kind 🦋, as long as the copyright notice and this paragraph are included on every copy and derivative work. BUT the document itself may not be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations 🙈. The only exceptions are when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or when it's being translated into a language other than English 🌈.

The permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them 💜.

This document and the information in it is provided "AS IS", 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. 💀

📦 where this page comes from