rfc-2846

GSTN Address Element Extensions in E-mail Services

C. Allocchio
date2000-06 streamIETF areaapp wgfax statusPROPOSED STANDARD pages35 canonicalhttps://www.rfc-editor.org/rfc/rfc2846 doi10.17487/RFC2846 errataview
This memo defines a full syntax for a specific application in which there is a need to represent GSTN (Global Switched Telephone Network) addressing and Internet addressing. [STANDARDS-TRACK]

updated by

Extracted elements (27)

design-rationale §2.1

The local-phone element was introduced because the global-phone (E.164 "+" prefix) numbering scheme does not cover all GSTN dialing scenarios, particularly local or national calls requiring exit codes, long-distance carrier access codes, or access passwords that precede the actual phone number.

email

design-rationale §3

The pstn-recipient element was designed to serve both originator and recipient roles using a single compact syntax, with elements labelled 'recipient' also usable for originator information. This avoids defining duplicate parallel structures for the two roles.

email

design-rationale §3.2

The qual2-label naming convention was intentionally made different from ITU F.401 labels to avoid conflict with X.400 addressing rules, even though the semantic meaning of the elements is derived from F.401. Other specifications extending this mechanism are cautioned to likewise avoid F.401 label names.

email

interoperability-note §2.1

A local-phone specification should be used only by the destination MTA specified by mta-I-pstn. Per RFC 1123, other intermediate MTAs should transfer the message without modifying the local-part (LHS), preserving the local-phone encoding intact.

email

interoperability-note §1

Efforts were made to maintain compatibility with MIXER (RFC 2156) gateway specifications. The pers-name definition (surname, givenname, initials) is taken directly from the MIXER specification to ensure interoperability with existing e-mail/X.400 gateways.

email

interoperability-note §2.1

The interpretation of pause ("p") and tonewait ("w") characters in local-phone numbers depends on the specific MTA implementation; their exact meaning is not defined in this specification. Both are case insensitive.

email

interoperability-note §12

The T33S qualif-type1 element (ITU T.33 fax subaddress) is restricted exclusively to the FAX service-selector and has no defined meaning outside the fax service.

email

normative-requirement §1 MUST

GSTN addresses in e-mail MAY contain additional elements defined elsewhere, but MUST use definitions from this memo for elements specified herein. In particular, service-selector names and qualif-type1 elements MUST be registered with IANA and published in the Assigned Numbers document.

email, registry

normative-requirement §10 MUST NOT

IANA MUST NOT accept registrations that are not supplemented by a Specification as defined in RFC 2434 and not fully specified using the template forms. In cases requiring further consultation, IANA SHOULD refer to the Application Area Director.

registry, email

normative-requirement §3.2 MUST

Only the strictly needed qualifier elements SHOULD be used, and the maximum total length of the pstn-email address MUST NOT exceed the limits specified in RFC 822 and RFC 1123.

email

normative-requirement §2.1 MUST NOT

The "+" character is reserved for global-phone addresses per ITU E.164 and MUST NOT be used as the starting character in a local-phone string.

email

normative-requirement §3.1 MUST

The pstn-address element in all its components and extensions MUST strictly follow the quoting rules specified in the relevant e-mail standards (RFC 822 and RFC 1123).

email

normative-requirement §4 REQUIRED

When multiple subaddresses are present for the same global-phone, the use of multiple pstn-email elements is REQUIRED. The UA MAY accept multiple subaddress elements, but MUST generate multiple pstn-mbox elements when submitting the message to the MTA.

email

protocol-element §3

The extended pstn-address definition is: pstn-address = pstn-mbox [ qualif-type1 ] or pstn-address = pstn-mbox [ pstn-recipient ] [ qualif-type1 ], allowing an optional recipient block and additional service-specific qualifiers after the core phone address.

email

protocol-element §2

The extended pstn-mbox format is: service-selector "=" gstn-phone [ sub-addr-spec ] [ post-sep post-dial ]. This supersedes the minimal form and adds support for ISDN subaddresses and post-dial sequences.

email

protocol-element §2

The gstn-phone element is defined as the union of global-phone and local-phone: gstn-phone = ( global-phone / local-phone ). This extends the minimal pstn-mbox definition from RFC 2303 to cover alternative national numbering schemes.

email

protocol-element §2.1

The local-phone element is defined as: local-phone = [ exit-code ] [ dial-number ], where both exit-code and dial-number are phone-string. It supports complex dialing sequences including outside-line access digits, long-distance carrier codes, and access passwords.

email

protocol-element §3

The pstn-recipient element is defined as: pstn-recipient = [ recipient-name ] [ 1*( recipient-qualifier ) ]. It optionally supplements the pstn-mbox with originator and/or recipient name and physical address details, particularly for onramp/offramp gateways.

email

protocol-element §3.2

The recipient-qualifier is an extensible element defined as: qualif-type2 = "/" qual2-label "=" string, where qual2-label includes ORG, OFNO, OFNA, STR, ADDR, ADDU, ADDL, POB, ZIP, and CO for physical delivery addressing.

email

registry §10

This document establishes an IANA registry for GSTN address qualif-type1 keyword and value elements. Initial registered values are: T33S, ISUB, POSTD, ATTN, ORG, OFNO, OFNA, STR, ADDR, ADDU, ADDL, POB, ZIP, and CO. The template in Appendix B.2 must be used for new registrations.

registry, email

security-consideration §7 SHOULD

GSTN services may require dialing of private codes (e.g., PINs) embedded in the local-phone field. Because e-mail addresses are transmitted without encoding across MTAs, these codes may be exposed to unauthorized parties or appear on fax cover pages. Senders SHOULD be provided methods such as code encryption or masquerading to prevent this disclosure.

security, email, privacy

security-consideration §7 SHOULD

Since e-mail routing relies on DNS, a successful DNS attack (server compromise, counterfeit responses, or poisoned additional-information records) could divert messages through a compromised MTA or gateway. Clients SHOULD base mail routing only on authoritative DNS answers and SHOULD employ DNS Security mechanisms once they are more widely deployed.

security, email, dns

wire-format §8

The complete pstn-email address format is: [ "/" ] pstn-address [ "/" ] "@" mta-I-pstn, where the optional leading and trailing "/" characters may be generated by gateways such as MIXER for compatibility with other services.

email

wire-format §2.2

The ISDN subaddress element sub-addr-spec uses the separator "/ISUB=" (case INSENSITIVE) followed by isub-addr, which is 1*( DIGIT ) or 1*( DIGIT / written-sep ). The written-sep is allowed only to enhance human readability.

email

wire-format §2.1

The phone-string element encodes dialing sequences as 1*( DTMF / pause / tonewait / written-sep ), where DTMF covers DIGIT / "#" / "*" / "A" / "B" / "C" / "D", pause is "p", tonewait is "w", and written-sep is "-" or ".".

email

wire-format §2.3

The post-dial element uses the separator "/POSTD=" (case INSENSITIVE) followed by a phone-string encoding the further dialing sequence needed to access additional services after the initial connection is established.

email

wire-format §3.1

The recipient-name is encoded as "/ATTN=" pers-name, where pers-name = [ givenname "." ] [ initials "." ] surname. The surname follows ITU F.401 printablestring; givenname allows digits, alpha, SP, and special characters.

email