As per Relevance of the word registration, we have this rfc below:
Network Working Group C.
Request for Comments: 3191 GARR-
Obsoletes: 2303 October 2001
Updates: 2846
Category: Standards
Minimal GSTN address format in Internet
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo describes a simple method of encoding Global
Telephone Network (GSTN) addresses (commonly called "
numbers") in the local-part of Internet email addresses, along
an extension mechanism to allow encoding of additional
attributes needed for email gateways to GSTN-based services
1.
As with all Internet mail addresses, the left-hand-side (local-part
of an address generated according to this specification, is not to
interpreted except by an MTA that handles messages for the
given in the right-hand-side
Since the very first e-mail to GSTN services gateway appeared,
number of different methods to specify a GSTN address as an e-
address have been used by implementors. Several objectives for
methods have been identified, like to enable an e-mail user to
GSTN services from his/her e-mail interface, to allow some kind
"GSTN over e-mail service" transport (possibly reducing the costs
GSTN long distance transmissions) while using the existing e-
infrastructure
Allocchio Standards Track [Page 1]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
This memo describes the MINIMAL addressing method to encode
addresses into e-mail addresses and the standard extension
to allow definition of further standard elements. The
problem, i.e., to allow a traditional numeric-only GSTN device
to access the e-mail transport service, is not discussed here
The IANA registration templates which MUST be used to register
standard element defined according to this specification are given
the "IANA Considerations" chapter (section 7 of this document).
All implementations supporting this GSTN over e-mail service
support as a minimum the specification described in this document
The generic complex case of converting the entirety of
addressing into e-mail is out of scope in this minimal specification
1.1 Terminology and Syntax
In this document the formal definitions are described using
syntax, as defined into [7]. This memo also uses some of the "
DEFINITIONS" defined in "APPENDIX A - CORE" of that document.
exact meaning of the capitalized
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL
is defined in reference [6].
In this document the following new terms are also defined
I-pstn device
a device which has an Internet domain name and it is able
communicate either directly or indirectly with the
network
mta-I-pstn
the Internet domain name which identifies uniquely an I-
device over the Internet
pstn-email
the complete Internet e-mail address structure which is used
transport a GSTN address over the Internet e-mail service
2. Minimal GSTN
The minimal specification of a GSTN address within an e-mail
is as follows
Allocchio Standards Track [Page 2]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
pstn-address = pstn-mbox [ qualif-type1 ]
pstn-mbox = service-selector "=" global-
service-selector = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed
; service-selector
; service-selector MUST be handled as a
; INSENSITIVE string by implementations
Other specifications adopting the "pstn-address" definition
define and register with IANA a unique case
"service-selector" element to identify the specific messaging
involved
These specifications and registrations MUST also define which
"qualif-type1" extensions, if any, MUST be supported for
specified messaging service
Implementations confirming to this minimal requirements
are allowed to ignore any other non-minimal extensions
element which is present in the "pstn-address". However,
implementations MUST preserve all "qualif-type1" address
they receive
The generic "qualif-type1" element is defined as
qualif-type1 = "/" keyword "="
keyword = 1*( DIGIT / ALPHA / "-" )
; note that SP (space) is not allowed in
string =
; note that printable characters are %x20-7
As such, all "pstn-address" extension elements MUST be defined in
"qualif-type1" form at the time of registration with IANA
2.1 Minimal "global-phone"
The purpose of global-phone element is to represent standard E.164
numeric addresses [10] within a syntax for electronic mail
that is compliant with standard e-mail specifications given in [1]
and [2].
Allocchio Standards Track [Page 3]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
The minimal supported syntax for global-phone element is as follows
global-phone = "+" 1*( DIGIT / written-sep )
written-sep = ( "-" / "." )
The use of other dialing schemes for GSTN numbers (like
numbering plans or local dialing conventions) is also allowed
However, this does not preclude nor remove the mandatory
for support to the "global-phone" syntax within the minimal
address format
Any other dialing schemes MUST NOT use the leading "+" defined
between the "=" sign and the dialing string. The "+" sign
strictly reserved for the standard "global-phone" syntax
Note
The specification of alternate dialing schemas is out of scope
this minimal specification
This document also permits the use of written-sep elements in
to improve human readability of GSTN e-mail addresses.
written-sep are elements which can be placed between dial
such as digits etc
Implementors' note
Use of the written-sep elements is allowed, but not
for transmission. Any occurrences of written-sep elements in
pstn-mbox MUST be ignored by all conformant implementations
2.2 The minimal "pstn-address"
Some examples of minimal pstn-address are
VOICE=+3940226338
FAX=+12027653000/T33S=6377
SMS=+33-1-88335215
Note
these examples are given as illustrations only; they do
necessarily represent valid pstn-addresses
Allocchio Standards Track [Page 4]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
3. The e-mail address of the I-pstn device: mta-I-
An "I-pstn device" has, among its characteristics, a unique
domain name which identifies it on the Internet. Within
mail, this is the Right Hand Side (RHS) part of the address, i.e.,
the part on the right of the "@" sign. For purposes of this
we will call this "mta-I-pstn
mta-I-pstn =
For "domain" strings used in SMTP transmissions, the string
conform to the requirements of that standards
[1], [3]. For "domain" strings used in message content headers,
string MUST conform to the requirements of the relevant
[2], [3].
Note
the use of "domain names" or "domain literals" is permitted
addresses in both the SMTP envelope and message header fields
4. The pstn-
The complete structure used to transfer a minimal GSTN address
the Internet e-mail transport system is called "pstn-email".
object is a an e-mail address which conforms to [2] and [3]
"addr-spec" syntax, with structure refinements which allows the
number to be identified
pstn-email = ["""] ["/"] pstn-address ["/"] ["""] "@" mta-I-
Implementors' note
The optional "/" characters can result from translations
other transport gateways (such as some X.400 gateways) which
included the "/" as an optional element. Implementations
accept the optional slashes but SHOULD NOT generate them
Gateways are allowed to strip them off when converting to
mail addressing. The relevant standard [2], [3] define
when the optional "quotes" characters surrounding the entire
part (i.e., the part on the left of the "@" character into
pstn-email) MUST be added
4.1 Multiple
There are some instances in GSTN applications where
subaddresses are used. On the other hand in e-mail practice
separate and unique e-mail address is always used for each recipient
Allocchio Standards Track [Page 5]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
In the event a particular GSTN service requires multiple
(in any form defined by the standard specification for that
service) that are associated with the same "pstn-mbox", then the
of multiple "pstn-email" elements is REQUIRED
Implementors' note
The UA may accept multiple subaddress elements for the
global-phone, but it MUST generate multiple "pstn-mbox"
when submitting the message to the MTA
4.2 Some examples of minimal "pstn-email"
Some examples of minimal pstn-email addresses follows
VOICE=+3940226338@worldvoice.
FAX=+1.202.7653000/T33S=6377@faxserv.
/SMS=+33-1-88335215/@telecom.
Note
these examples are given as illustrations only; they do
necessarily represent valid pstn-addresses
5.
This proposal creates a minimal standard encoding for GSTN
within the global e-mail transport system. It also defines
standard extension mechanism to be used to introduce new elements
GSTN addresses
The proposal is consistent with existing e-mail standards.
specific GSTN service using this proposal MUST define and
with IANA its own "service-selector" specification and MUST
and register the eventual other "qualif-type1" elements needed
its specific application. An example of such an application
contained in reference [13].
6. Security
This document specifies a means by which GSTN addresses can
encoded into e-mail addresses. Since e-mail routing is determined
Domain Name System (DNS) data, a successful attack to DNS
disseminate tampered information, which causes e-mail messages to
diverted via some MTA or Gateway where the security of the
has been compromised
Allocchio Standards Track [Page 6]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
There are several means by which an attacker might be able to
incorrect mail routing information to a client. These include: (a
compromise of a DNS server, (b) generating a counterfeit response
a client's DNS query, (c) returning incorrect "
information" in response to an unrelated query. Clients
ensure that mail routing is based only on authoritative answers
Once DNS Security mechanisms [5] become more widely deployed,
SHOULD employ those mechanisms to verify the authenticity
integrity of mail routing records
7. IANA
As the service-selector and qualif-type1 elements values
extensible, they MUST be registered with IANA
To register a service-selector or a qualif-type1 element,
registration form templates given in 7.1 and 7.2 MUST be used.
new registration MUST fulfill the "Specification Required" criteria
as defined in RFC 2434, section 2 [16]:
"Specification Required - Values and their meaning MUST
documented in an RFC or other permanent and readily
reference, in sufficient detail so that interoperability
independent implementations is possible."
IANA MUST NOT accept registrations which are not supplemented by
Specification as defined above and which are not fully
according to the template forms given in 7.1 and 7.2. In case
need for further consultation about accepting a new registration
IANA SHOULD refer to the Application Area Director to be directed
the appropriate "expert" individual or IETF Working Group
After successful registration, IANA should publish the registered
element in the appropriate on-line IANA WEB site, and include it
the updates of the "Assigned Numbers" RFC series
This section (including 7.1 and 7.2) updates the ones contained
[15].
7.1 IANA Registration form template for new values of
address service-
To: IANA@iana.
Subject: Registration of new values for the GSTN
service-selector specifier "foo
Allocchio Standards Track [Page 7]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
service-selector name
Description of Use
foo - ("foo" is a fictional new service-selector used in
template as an example, it is to be replaced with the new
being registered. Include a short description of the use of
new value here. This MUST include reference to Standard
RFCs and eventually to other Standard Bodies documents for
complete description; the use of the value must be
completely enough for independent implementation).
Security Considerations
(Any additional security considerations that may be introduced
use of the new service-selector parameter should be defined
or in the reference Standards Track RFCs
Person & email address to contact for further information
(fill in contact information
INFORMATION TO THE SUBMITTER
The accepted registrations will be listed in the "
Numbers" series of RFCs. The information in the registration
is freely distributable
7.2 IANA Registration form template for new values of
address qualif-type1 keyword and
To: IANA@iana.
Subject: Registration of new values for the GSTN
qualif-type1 element "bar
qualif-type1 "keyword" name
qualif-type1 "value" ABNF definition
abnf - ("abnf" MUST define the ABNF form of the qualif-type
value. The ABNF specification MUST be self-contained, using
basic elements the tokens given in specification [4]. To
any duplication (when appropriate), it MUST also use any
Allocchio Standards Track [Page 8]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
registered non-basic token from other qualif-type1 elements, i.e.,
it MUST use the same non-basic token name and then repeat
identical ABNF definition from basic tokens
Description of Use
bar - ("bar" is a fictional description for a new qualif-type
element used in this template as an example. It is to be
by the real description of qualif-type1 element being registered
Include a short description of the use of the new qualif-type
here. This MUST include reference to Standards Track RFCs
eventually to other Standard Bodies documents for the
description; the use of the value MUST be defined
enough for independent implementation.)
Use Restriction
(If the new qualif-type1 elements is meaningful only for
specific set of service-element, you MUST specify here the list
allowed service-element types. If there is no restriction,
specify the keyword "none")
Security Considerations
(Any additional security considerations that may be introduced
use of the new service-selector parameter should be defined
or in the reference Standards Track RFCs
Person & email address to contact for further information
(fill in contact information
INFORMATION TO THE SUBMITTER
The accepted registrations will be listed in the "
Numbers" series of RFCs. The information in the registration
is freely distributable
8. Changes from RFC 2303
Although there are no technical or major changes from RFC 2303
specification, this section briefly describes where updates
clarifications were introduced
Allocchio Standards Track [Page 9]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
- considering the case that telephony systems do not conform
more to the "single/few" Public Operator paradigm, the
definition "PSTN - Public Switched Telephone Network" was
into the more adequate "GSTN - Global Switched Telephone Network
one. However, in order to remain consistent with the
specification, the ABNF variables names were not changed
- it was made clear that "GSTN addresses" correspond, in
language, to "telephone numbers" and that the "global-phone" is
representation of E.164 numeric addresses
- an explicit list of "new terms" with explanations was added
section 1.1;
- the fact that any other specification adopting the "pstn-address
definition MUST register with IANA the new "service-selector"
"qualif-type1" elements was made explicit throughout the document
the relevant mechanism to be used was added in section 7 "
considerations" (including the IANA Registration form templates);
this is also consistent with RFC 2846;
- in section 2.1 the use and meaning of "written-sep" was clarified
- in section 4., the quoting rules of the "pstn-address" and
practical use was made explicit both in the definition
pstn-email" and in the Implementors' note
- section 4.1 was updated to clarify how to generate "pstn-email
when more than one subaddress is used
- the Author's Address was updated
- the References list was updated to include RFC 2846 and RFC 2434.
Allocchio Standards Track [Page 10]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
9. Author's
Claudio
INFN-
c/o Sincrotrone
SS 14 Km 163.5
I 34012
RFC2822: Claudio.Allocchio@garr.
X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio
Phone: +39 040 3758523
Fax: +39 040 3758565
10.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet
Messages", STD 11, RFC 822, August 1982.
[3] Braden, R., "Requirements for Internet hosts - application
support", STD 3, RFC 1123, October 1989.
[4] Malamud, C. and M. Rose, "Principles of Operation for
TPC.INT Subdomain: Remote Printing -- Technical Procedures",
1528, October 1993.
[5] Eastlake, D. and C. Kaufman, "Domain Name System
Extensions", RFC 2065, January 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[7] Crocker, D. and P. Overell, "Augmented BNF for
Specifications", RFC 2234, November 1997.
[8] ITU F.401 - Message Handling Services: Naming and Addressing
Public Message Handling Service; recommendation F.401 (
1992).
[9] ITU F.423 - Message Handling Services:
Between the Interpersonal Messaging Service and the
Service; recommendation F.423 (August 1992).
[10] ITU E.164 - The International Public Telecommunication
Plan E.164/I.331 (May 1997).
Allocchio Standards Track [Page 11]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
[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
acoustical coupling to the microphone of a handset
(March 1995).
[13] Allocchio, C., "Minimal FAX address format in Internet Mail",
RFC 3192, October 2001.
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[15] Allocchio, C. "GSTN address element extensions in e-
services", RFC 2846, June 2000.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Allocchio Standards Track [Page 12]
RFC 3191 Minimal GSTN address format in Internet Mail October 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Allocchio Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
