Minimal GSTN address format in Internet Mail
obsoletes
- rfc-2303 — Minimal PSTN address format in Internet Mail
updates
- rfc-2846 — GSTN Address Element Extensions in E-mail Services
Extracted elements (25)
The specification intentionally covers only the minimal GSTN-over-email direction; the reverse problem (allowing numeric-only GSTN device users to access e-mail) is explicitly out of scope, keeping the specification focused and implementable.
The terminology was changed from 'PSTN - Public Switched Telephone Network' to 'GSTN - Global Switched Telephone Network' to reflect that telephony systems no longer conform to a single or few Public Operator paradigm. ABNF variable names were kept unchanged for consistency with RFC 2303.
Written separators ("-" and ".") are permitted in global-phone for human readability but are not recommended for transmission and must be ignored by implementations. This balances human convenience against wire cleanliness.
The optional '/' characters in pstn-email addresses can result from translations by X.400 gateways; implementations must accept them for backward compatibility, but should not generate them in new implementations.
All implementations supporting GSTN over e-mail MUST support as a minimum the specification described in this document.
Any occurrences of written-sep elements ("-" or ".") in a pstn-mbox MUST be ignored by all conformant implementations.
Any other dialing schemes (non-E.164) MUST NOT use the leading "+" sign between the "=" sign and the dialing string; the "+" is strictly reserved for the standard global-phone syntax.
Conforming implementations MUST preserve all qualif-type1 address elements they receive, even though they are allowed to ignore non-minimal extension elements.
For domain strings in SMTP transmissions, the mta-I-pstn MUST conform to SMTP domain specifications (RFC 821, RFC 1123). For message content headers, it MUST conform to RFC 822 requirements.
IANA MUST NOT accept registrations not supplemented by the required specification and not fully specified using the template forms in sections 7.1 and 7.2.
Implementations MUST accept the optional slash characters in pstn-email addresses but SHOULD NOT generate them. Gateways are allowed to strip them off when converting to Internet mail addressing.
New service-selector and qualif-type1 registrations MUST fulfill the 'Specification Required' criteria: values and meaning MUST be documented in an RFC or other permanent reference in sufficient detail for independent interoperable implementations.
service-selector MUST be handled as a case-insensitive string by implementations.
Specifications adopting the pstn-address definition MUST define and register with IANA a unique case-insensitive service-selector element and MUST define which minimal qualif-type1 extensions are required for that service.
When a GSTN service requires multiple subaddresses for the same pstn-mbox, the use of multiple pstn-email elements is REQUIRED. The UA MUST generate multiple pstn-mbox elements when submitting to the MTA.
The 'mta-I-pstn' is the Internet domain name (right-hand side of '@') that uniquely identifies an I-pstn device — a device with an Internet domain name capable of communicating with the GSTN network. It forms the routing target for pstn-email delivery.
The 'pstn-address' is the core structure encoding a GSTN address: a service-selector string followed by '=' and a global-phone, with an optional qualif-type1 extension. The service-selector identifies the specific messaging service (e.g., VOICE, FAX, SMS).
IANA registry for GSTN address qualif-type1 keyword and value elements. Each entry requires: keyword name, ABNF value definition, description of use, use restriction (allowed service-selectors or 'none'), security considerations, and contact. Template defined in section 7.2.
IANA registry for GSTN address service-selector values. Each entry requires: service-selector name, description of use (with reference to Standards Track RFCs), security considerations, and contact information. Template defined in section 7.1.
Because e-mail routing is determined by DNS data, a successful attack on DNS could cause messages to be diverted via a compromised MTA or gateway. Attack vectors include compromise of a DNS server, counterfeit DNS responses, and incorrect additional information in unrelated query responses.
Clients SHOULD ensure that mail routing is based only on authoritative DNS answers. Once DNS Security mechanisms (DNSSEC, RFC 2065) are more widely deployed, clients SHOULD employ them to verify authenticity and integrity of mail routing records.
ABNF for global-phone: 'global-phone = "+" 1*(DIGIT / written-sep)' where written-sep is "-" or ".". The leading "+" is strictly reserved for E.164 global-phone syntax and MUST NOT be used by other dialing schemes.
ABNF for pstn-address: 'pstn-address = pstn-mbox [qualif-type1]'; 'pstn-mbox = service-selector "=" global-phone'; service-selector is 1*(DIGIT / ALPHA / "-") and MUST be handled case-insensitively.
ABNF for the qualif-type1 extension: 'qualif-type1 = "/" keyword "=" string' where keyword is 1*(DIGIT / ALPHA / "-") and string is PCHAR (printable characters %x20-7E).
The complete pstn-email address structure: 'pstn-email = ["\"" ] ["/"] pstn-address ["/"] ["\"" ] "@" mta-I-pstn'. Optional slash characters may appear from X.400 gateway translations; optional quotes follow RFC 822/2822 addr-spec rules.