Network Working Group C. Allocchio
Request for Comments: 2303 GARR-Italy
Category: Standards Track March 1998
Minimal PSTN 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 (1998). All Rights Reserved.
IESG NOTE
This memo describes a simple method of encoding PSTN addresses in the
local-part of Internet email addresses, along with an extension
mechanism to allow encoding of additional standard attributes needed
for email gateways to PSTN-based services.
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).
1. Introduction
Since the very first e-mail to PSTN services gateway appeared, a
number of different methods to specify a PSTN address as an e-mail
address have been used by implementors. Two major objectives for this
were
- enable an e-mail user to access these services from his/her
e-mail interface;
- enable some kind of "PSTN over e-mail service" transport, to
reduce the costs of PSTN long distance transmissions, and use the
existing e-mail infrastructure.
Allocchio Standards Track [Page 1]
RFC 2303 Minimal PSTN in Internet Mail March 1998
This memo describes the MINIMAL addressing method to encode PSTN
addresses into e-mail addresses and the standard extension mechanism
to allow definition of further standard elements. The opposite
problem, i.e. to allow a traditional numeric-only PSTN device user to
access the e-mail transport service, is not discussed here.
All implementations supporting this PSTN over e-mail service MUST
support as a minimum the specification described in this document.
The generic complex case of converting the whole PSTN addressing into
e-mail is out of scope in this minimal specification: there is some
work in progress in the field, where also a number of standard
optional extensions are being defined.
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 capitalised words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"
is defined in reference [6].
2. Minimal PSTN address
The minimal specification of a PSTN address in e-mail address is as
follows:
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.
Specifications adopting the "pstn-address" definition MUST define a
unique case insensitive "service-selector" element to identify the
specific messaging service involved.
These specifications MUST also define which minimal "qualif-type1"
extensions, if any, MUST be supported for the specified service.
Implementations confirming to these minimal requirements
specification are allowed to ingnore any other non-minimal extensions
address element which can be present in the "pstn-address". However,
Allocchio Standards Track [Page 2]
RFC 2303 Minimal PSTN in Internet Mail March 1998
conforming implementations MUST preserve all "qualif-type1" address
elements they receive.
The generic "qualif-type1" element is defined as:
qualif-type1 = "/" keyword "=" string
keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in keyword
string = PCHAR
datatracker.ietf.org