< draft-ietf-fax-fulladdr   rfc2846.txt 
Network Working C. Allocchio Network Working Group C. Allocchio
Group GARR-Italy Request for Comments: 2846 GARR-Italy
INTERNET-DRAFT February 1999 Category: Standards Track June 2000
Expires: August 1999
File: draft-ietf-fax-fulladdr-05.txt
GSTN address element extensions in e-mail services GSTN Address Element Extensions in E-mail Services
Status of this Memo Status of this Memo
This document is an Internet Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. 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.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright (C) The Internet Society (2000). All Rights Reserved.
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at There are numerous applications where there is a need for interaction
http://www.ietf.org/shadow.html. between the GSTN addressing and Internet addressing. This memo
defines a full syntax for one specific case, where there is a need to
represent GSTN addresses within Internet e-mail addresses. This full
syntax is a superset of a minimal syntax which has been defined in
[1].
1. Introduction 1. Introduction
The possible elements composing a "Global Switched Telephone Network The possible elements composing a "Global Switched Telephone Network
(GSTN) address in e-mail" (formerly known also as Public Switched (GSTN) address in e-mail" (also known as the Public Switched
Telephone Network - PSTN) can vary from a minimum number up to a Telephone Network - PSTN) can vary from a minimum number up to a
really large and complex collection: the minimal format and general really large and complex collection. As noted the minimal format and
address syntax are defined in [1], together with the syntax to define general address syntax have been defined in [1], along with the
additional address elements. mechanism needed to define additional address elements. This memo
uses this extension mechanism to complete the syntax for representing
To ensure interoperability among different applications, also the GSTN addresses within e-mail addresses and contains the IANA
additional, and in most cases optional, address elements must be registrations for all newly defined elements.
defined in a standard syntax. In this memo we define some of these
additional address elements:
- the detailed definition of GSTN number formats, in order to cover In particular, the following additional address elements shall be
all the possible and different GSTN numbering schema (gstn-phone, defined:
sub-addr-spec and post-dial)
- the message originator / recipient specification (pstn-recipient) - the detailed definition of GSTN number formats, in order to cover
various alternative standard GSTN numbering schemes, (i.e. gstn-
phone, sub-addr-spec and post-dial)
The definitions included in this memo always superset the minimal - the message originator and/or recipient specification (pstn-
profile defined in [1]. The "incremental alternatives" syntax defined recipient)
in [4] is used to describe this fact.
GSTN addresses in e-mail MAY contain additional elements defined in GSTN addresses in e-mail MAY contain additional elements defined and
other specifications (see for example "T33S" element in [2]), but registered in other specifications (see for example "T33S" element in
they MUST use definitions contained in this memo for those elements [2]), but they MUST use definitions contained in this memo for those
already specified here. elements specified here.
In particular, "service-selector" names and "qualif-type1" elements In particular, "service-selector" names and "qualif-type1" elements
MUST be registered with IANA, and published within the "ASSIGNED MUST be registered with IANA, and published within the "ASSIGNED
NUMBERS" document. This will ensure an easy mechanism for extending NUMBERS" document. This provides a standard mechanism for extending
the element sets and will avoid unecessary duplication. IANA the element sets and should avoid unnecessary duplication. IANA
Registration form templates are provided in Appendix B. Registration form templates for the purpouse of registering new
A collection of forms for already defined "serivce-selector" and elements are provided in Appendix B. In addition the IANA
consideration section of this document defines the procedures
required to proceed with new registrations.
A collection of forms for already defined "service-selector" and
"qualif-type1" elements is listed in appendix C and appendix D "qualif-type1" elements is listed in appendix C and appendix D
respectively. Standard Track RFC specification MUST supplement the respectively.
definition of any new element registered with IANA. The use of
unregistered "X-" type "service-selector" and "qualif-type1" elements
is deprecated. See Appendix B - IANA Considerations for further details.
Even if in this memo we focus on e-mail addresses, a number of elements In particular, efforts have been made to maintain compatibility with
defined in this specification can also be used for other specifications elements defined in existing e-mail gateway services and standard
dealing with embedding GSTN addresses into other addresses: for example specifications. For example, to the extent possible, compatibility
there is some work in progress about URLs specification which adopts has been maintained with the MIXER [3] gateways specifications.
similar definitions, with slight changes in the global syntax due to
specific URL format.
Finally, in this memo we try to maintain maximum compatibility 1.1 Relationship with Internet addressing other than e-mail
with existing e-mail gateway services and standard specifications.
In particular we will use as much as possible compatible definitions Even if in this memo we focus on e-mail addresses, a number of
with MIXER [3] gateways specifications, in order to facilitate elements defined in this specification can also be used for other
transparent e-mail address translations without unduly complex mappings. specifications dealing with embedding GSTN addresses into other
addresses: for example there is some work in progress about URLs
specification which adopts similar definitions, with slight changes
in the global syntax due to specific URL format.
1.2 Terminology and Syntax conventions
In this document the formal definitions are described using ABNF In this document the formal definitions are described using ABNF
syntax, as defined into [4]. We will also use some of the "CORE syntax, as defined into [4]. We will also use some of the "CORE
DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The
exact meaning of the capitalised words exact meaning of the capitalised words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"
is defined in reference [5]. is defined in reference [5].
2. GSTN extended number and pstn-mbox extended format 2. GSTN extended number and pstn-mbox extended format
In reference [1], section 2, the minimal definition of pstn-mbox In reference [1], section 2, the minimal definition of pstn-mbox
includes the global-phone element, and further details are defined includes the global-phone element, and further details are defined in
in [1] section 2.1. [1] section 2.1.
However other non global-phone numbering schema are allowed, too. However other non global-phone numbering schemes are also possible.
In order to describe these more general schema, we thus expand the Thus, the minimal set syntax defined in [1] shall be extended to
scenario defining the GSTN extended number format: enable support for local-phone elements. Therefore, the gstn-phone
format is defined as follows:
gstn-phone = ( global-phone / local-phone ) gstn-phone = ( global-phone / local-phone )
The complexity of the GSTN system includes also the optional use of The complexity of the GSTN system includes also the optional use of
subaddresses and post dialling sequences. As a consequence the extended subaddresses and post dialling sequences. As a consequence, there is
definition of pstn-mbox becomes: a need to extend the definition of pstn-mbox per [1] to include
support for both the minimal set definition and an extended syntax.
The expanded definition of pstn-mbox is as follows:
pstn-mbox = service-selector "=" global-phone pstn-mbox = service-selector "=" global-phone
pstn-mbox =/ service-selector "=" gstn-phone pstn-mbox =/ service-selector "=" gstn-phone
[ sub-addr-spec ] [post-sep post-dial] [ sub-addr-spec ] [post-sep post-dial]
NOTE: see section 4 in case multiple sub-addr-spec per pstn-mbox need NOTE: see section 4 in the event multiple "sub-addr-spec" elements
to be specified. per pstn-mbox need to be specified.
2.1 The local-phone syntax 2.1 The local-phone syntax
The local-phone element can be used to represent all possible cases The local-phone element is intended to represent the set of possible
where the global-phone does not apply. In order to cover all possible cases where the global-phone numbering schema does not apply. Given
different and complex conventions in use in the GSTN system, the the different and complex conventions currently being used in the
local-phone definition allows a large number of elements. Please GSTN system, the local-phone definition supports a large number of
note that local-phone MUST NOT start with a "+" sign, as this is elements.
reserved for global-phone definition.
We now define in details local-phone: The detailed syntax for local-phone elements follows:
local-phone = [ exit-code ] [ dial-number ] local-phone = [ exit-code ] [ dial-number ]
exit-code = phone-string exit-code = phone-string
; this include anything needed to enable dialling, like ; this will include elements such as the digit to
; the digit to access outside line, the long distance ; access outside line, the long distance carrier
; carrier access code, the access password to the service, ; access code, the access password to the service,
; etc... ; etc...
dial-number = phone-string dial-number = phone-string
; this is in many cases composed of different elements ; this is in many cases composed of different elements
; like the local phone number, the area code (if needed), ; such as the local phone number, the area code
; the international country code (if needed), etc... ; (if needed), the international country code
; (if needed), etc...
Note:
the "+" character is reserved for use in global-phone addresses
per [7] and MUST NOT be used as the starting character in a
local-phone string.
phone-string = 1*( DTMF / pause / tonewait / written-sep ) phone-string = 1*( DTMF / pause / tonewait / written-sep )
DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
; special DTMF codes like "*", "#", "A", "B", ; special DTMF codes like "*", "#", "A", "B",
; "C", "D" are defined in [6] ; "C", "D" are defined in [6]
; Important Note: this is NOT the alpha to digit ; Important Note: these elements only apply for
; convention in use in some countries. ; alphabetic strings used in DTMF operations.
; They are NOT applicable for the alphabetic
; characters that are mapped to digits on phone
; keypads in some countries.
pause = "p" pause = "p"
tonewait = "w" tonewait = "w"
NOTE: "pause" and "tonewait" character interpretation in local-phone numbers The written-sep element is defined in [1], section 2.1.
depends on the specific MTA implementation. Thus its exact meaning
need not to be defined here. Both "pause" and "tonewait" are case
insensitive.
The written-sep is defined in [1], section 2.1; other specification for Note:
some particular services (like for example voice messaging service) CAN "pause" and "tonewait" character interpretation in local-phone
allow additional separators. Their definition MUST be detailed into numbers depends on the specific MTA implementation. Thus its exact
the documents defining the addressing for the specific service. meaning is not defined here. Both "pause" and "tonewait" are case
insensitive.
Important Note: Important Note:
A local-phone specification is a sequence which should be dialled A local-phone specification is a sequence which should be used
by the MTA specified by mta-I-pstn (see [1], section 3) to reach only by the destination MTA specified by mta-I-pstn (see [1],
the destination device. Other MTAs should only transfer the message section 3). Per [12], other MTAs should transfer the message
around without modification until the destination MTA is reached. without modifying the LHS.
However, this implementation scenario is extremely complex and full
discussion of it is outside the scope of this document.
2.2 The sub-addr-spec element 2.2 The sub-addr-spec element
In GSTN service there are cases where a sub-addr-spec is required to In GSTN service there are cases where a sub-addr-spec is required to
specify the final destination. In particular there are ISDN subaddresses specify the final destination. In particular there are ISDN
[7], which apply to all possible services, while other types are subaddresses [7], which apply for various services, whereas other
limited to specific services (see the fax service T.33 subaddress [8], subaddress types may be service specific (see the fax service T.33
[2]). subaddress [8], [2]).
We must thus be able to specify at least the ISDN subaddress, remembering Within actual telephone operations there may be cases where different
that an ISDN subaddress could be supplemented by other subaddress types types of subaddresses are used as part of a single complete address.
(like a fax T.33 [8] subaddress). Therefore, the sub-addr-spec syntax definition which follows defines
the subaddress element for the context of ISDN use; the T.33
subaddress element is defined in [2], section 2.
As a consequence, the definition of sub-addr-spec is: The definition of sub-addr-spec is:
sub-addr-spec = [ isdn-sep isub-addr ] sub-addr-spec = [ isdn-sep isub-addr ]
In detail: In detail:
isdn-sep = "/ISUB=" isdn-sep = "/ISUB="
; note that "/ISUB=" is case INSENSITIVE ; note that "/ISUB=" is case INSENSITIVE
isub-addr = 1*( DIGIT ) isub-addr = 1*( DIGIT )
isub-addr =/ 1*( DIGIT / written-sep ) isub-addr =/ 1*( DIGIT / written-sep )
The IANA registration form for sub-addr-spec is given in appendix D.2 The IANA registration form for sub-addr-spec is given in appendix D.2
2.3 The post-dial element 2.3 The post-sep and post-dial elements
In some cases, after the connection with the destination GSTN In some cases, after the connection with the destination GSTN device
device has been established, a further dialling sequence can be has been established, a further dialling sequence is required to
required to access further services; a typical example are the access further services. A typical example is an automated menu-
automated menu-driven services using DTMF sequences on the driven service using DTMF sequences. These cases may be handled using
telephone services. These sequences are defined as a separator "post-sep" and "post-dial" elements as defined below:
and a post dial sequence:
post-sep = "/POSTD=" post-sep = "/POSTD="
; note that "/POSTD=" is case INSENSITIVE ; note that "/POSTD=" is case INSENSITIVE
post-dial = phone-string post-dial = phone-string
A number of gstn-phone examples are listed in section 4.
The IANA registration form for post-sep and post-dial are given in The IANA registration form for post-sep and post-dial are given in
appendix D.3 appendix D.3
3. The pstn-recipient 3. The pstn-recipient
The pstn-mbox element is sometimes not enough to specify additional There are some application where it is valuable to supplement the
Details, like the originator / recipient name, physical address, etc. pstn-mbox element with additional details. Common examples include
The optional pstn-recipient element provides information which could the use of originator and/or recipient names and physical addresses,
also be used by the onramp / offramp gateway to specify the originator / particularly in the context of onramp and/or offramp gateways.
recipient exactly. In many cases the pstn-recipient element will be
used for recipient addresses: however also originator addresses could The optional pstn-recipient element provides support for such
be specified using pstn-mbox and pstn-recipient, in particular if onramp details.
gateways are involved.
As an example, when an offramp fax gateway is involved, the As an example, when an offramp fax gateway is involved, the
pstn-recipient element could be used to specify the intended recipient pstn-recipient element could be used to specify the intended
on a fax cover page; again the fax cover page headers could be qualified recipient on a fax cover page, and the fax cover page headers could
using the originator pstn-recipient information. be qualified using the originator pstn-recipient information.
Please note: in this document many ABNF variables contain the "recipient" In the interest of a compact syntax, the pstn-recipient element may
token, but all these elements can be applied both to originator / recipient be used to support both originator and recipient addresses. For all
addresses. cases within the ABNF definitions to follow, the elements labelled
with "recipient" may also be used for originator information.
The pstn-recipient is a sequence of qualif-type1 elements, as defined The pstn-recipient is a sequence of qualif-type1 elements as defined
in [1], section 2: below:
pstn-recipient = [ recipient-name ] pstn-recipient = [ recipient-name ]
[ 1*( recipient-qualifier ) ] [ 1*( recipient-qualifier ) ]
As a consequence, the extended definition of pstn-address becomes: As a consequence, the extended definition of pstn-address becomes:
pstn-address = pstn-mbox [ qualif-type1 ] pstn-address = pstn-mbox [ qualif-type1 ]
pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ] pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
The definition for qualif-type1 elements is contained in [1] section
2.
3.1 The recipient-name 3.1 The recipient-name
The recipient-name specifies the personal name of the originator / The recipient-name specifies the personal name of the originator
recipient: and/or recipient:
recipient-name = "/ATTN=" pers-name recipient-name = "/ATTN=" pers-name
pers-name = [ givenname "." ] pers-name = [ givenname "." ]
[ initials "." ] [ initials "." ]
surname surname
The following definitions come directly from MIXER specification [3]: The following definitions come directly from the MIXER specification
[3]:
surname = printablestring surname = printablestring
givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" / givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" /
"," / "-" / "/" / ":" / "=" / "?" ) "," / "-" / "/" / ":" / "=" / "?" )
initials = 1*ALPHA initials = 1*ALPHA
NOTE: the "initials" element does not simply specify the Note:
middle initial which is common in some countries; it the "initials" element can specify the middle initial which is
allows the complete set of givennames initials in any common in some countries; however it is also possible to support
possible combination. See examples at section 5.2 multiple initials, which may be commonly used in other countries.
This allows the complete set of givennames initials in any
possible combination. See examples at section 5.2
It is essential to remember that "pstn-address" element (in all its It is essential to remember that the "pstn-address" element (in all
components and extensions) MUST strictly follow the "quoting rules" its components and extensions) MUST strictly follow the "quoting
spcified in the relevant standards [11], [12]. rules" specified in the relevant e-mail standards [11], [12].
The IANA registration form for recipient-name is given in appendix D.4 The IANA registration form for recipient-name is given in appendix
D.4.
3.2 The extensible recipient-qualifier 3.2 The extensible recipient-qualifier
The recipient-name is sometimes not enough to specify completely the The recipient-name is sometimes not enough to specify completely the
originator / recipient. An additional set of optional elements, whose originator and/or recipient. An additional set of optional elements,
specific definition is in most cases application dependent, is thus whose specific definition is in most cases application dependent, is
defined: thus defined:
recipient-qualifier = ( qualif-type1 / qualif-type2 ) recipient-qualifier = ( qualif-type1 / qualif-type2 )
The recipient-qualifier is a qualif-type1 element, and contains The recipient-qualifier is a qualif-type1 element, and contains a
a qualif-type1 element in a recursive definition which allows an qualif-type1 element in a recursive definition which allows an
extensible format. However we define at least a number of these extensible format. The purpouse of qualif-type2 element is to permit
elements, calling them "qualif-type2" additional extensibility for items which go beyond the scope of those
defined for use with the qualif-type1 element.
A series of qualif-type2 elements are defined below:
qualif-type2 = "/" qual2-label "=" string qualif-type2 = "/" qual2-label "=" string
qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR" qual2-label = "ORG" / "OFNO" / "OFNA" / "STR" / "ADDR"
"ADDU" / "ADDL" / "POB" / "ZIP" / "CO" "ADDU" / "ADDL" / "POB" / "ZIP" / "CO"
string = PCHAR string = PCHAR
; note that printable characters are %x20-7E ; note that printable characters are %x20-7E
printablestring = 1*( DIGIT / ALPHA / SP / printablestring = 1*( DIGIT / ALPHA / SP /
"'" / "(" / ")" / "+" / "," / "-" / "'" / "(" / ")" / "+" / "," / "-" /
"." / "/" / ":" / "=" / "?" ) "." / "/" / ":" / "=" / "?" )
; this definition comes from ITU F.401 [9] ; this definition comes from ITU F.401 [9]
; and MIXER [3] ; and MIXER [3]
We briefly describe in Table 1 the meaning of qual2-label fields: Table 1 includes short definition of qual2-label fields:
Table 1 - qual2-label Table 1 - qual2-label
qual2-label Description qual2-label Description
----------------------------------------------------------------- -----------------------------------------------------------------
"ORG" Organization Name for Physical Delivery (example: ACME Inc) "ORG" Organization Name for Physical Delivery (example: ACME
Inc)
"OFNO" Office Number for physical delivery (example: BLD2-44) "OFNO" Office Number for physical delivery (example: BLD2-44)
"OFNA" Office Name for physical delivery (example: Sales) "OFNA" Office Name for physical delivery (example: Sales)
"STR" Street address for physical delivery (example: "STR" Street address for physical delivery (example:
45, Main Street) 45, Main Street)
"ADDR" Unformatted postal address for physical delivery "ADDR" Unformatted postal address for physical delivery
(example: HWY 14, Km 94.5 - Loc. Redhill) (example: HWY 14, Km 94.5 - Loc. Redhill)
skipping to change at line 338 skipping to change at page 8, line 35
ACMETELEX) ACMETELEX)
"ADDL" Local postal attributes for physical delivery (example: "ADDL" Local postal attributes for physical delivery (example:
Entrance 3, 3rd floor, Suite 296) Entrance 3, 3rd floor, Suite 296)
"POB" Post Office Box for physical delivery "POB" Post Office Box for physical delivery
"ZIP" Postal ZIP code for physical delivery "ZIP" Postal ZIP code for physical delivery
"CO" Country Name for physical delivery "CO" Country Name for physical delivery
-----------------------------------------------------------------
One or a combination of some of the above elements are usually enough One or a combination of some of the above elements is usually enough
to exactly specify the originator / recipient of the message. The use to exactly specify the originator and/or recipient of the message.
of a large number of these elements could in fact create a very long The use of a large number of these elements could in fact create a
recipient-qualifier. Thus only the strictly needed elements SHOULD very long recipient-qualifier. Thus, only the strictly needed
be used. The maximum total length of the pstn-email MUST in fact elements SHOULD be used. The maximum total length of the pstn-email
not exceed the limits specified in the relevant standards [11] [12]. MUST in fact not exceed the limits specified in the relevant e-mail
standards [11] [12].
IMPORTANT NOTE: even if the meaning of the above elements is derived IMPORTANT NOTE: Although the meaning of the above elements is derived
directly from similar elements available in F.401 specification [9] directly from similar elements available in F.401 specification [9],
their names is explicitly different, in order not to conflict with the naming convention used in this document is explicitly different.
specific X.400 addressing rules. Also any additional qualif-type1 In this way a conflict is avoided with related X.400 addressing
element defined in different specification SHOULD use different rules. Other specification which use the extension mechanism of this
label names to avoid possible conflicts. document to define new qualif-type1 elements which overlap with F.401
are cautioned to create new labels which are different than those
used in F.401.
The IANA registration form for these elements is given in appendix The IANA registration form for these elements is given in appendix
D.5 to D.14 D.5 to D.14.
4. Multiple sub-addr-spec cases 4. Multiple sub-addr-spec cases
In case there are multiple sub-addr-spec to be given on the same There are some instances in GSTN applications where multiple
pstn-mbox then multiple pstn-email elements will be used. The UA could subaddresses are used: T.33 subaddresses in fax service are one of
accept multiple sub-addr-spec elements for the same global-phone / these cases. In e-mail practice a separate and unique e-mail address
local-phone, but it MUST generate multiple pstn-mbox, when passing the is always used for each recipient; as such, if multiple subaddresses
message to the MTA. are present, the use of multiple "pstn-email" elements [1] is
REQUIRED.
Implementors' note:
The UA MAY accept multiple subaddress elements for the same
global-phone, but it MUST generate multiple "pstn-mbox" elements
when submitting the message to the MTA.
5. Examples 5. Examples
In order to clarify the specification we present here a limited In order to clarify the specification we present here a limited set
set of examples. Many of the examples refer to the fax service, of examples. Many of the examples refer to the fax service, but also
but also additional possible services are included. Check also additional possible services are included. Check also the examples in
the examples in [1] and [2] for additional information. [1] and [2] for additional information. Please note that all the
examples are for illustration purpouses, only.
5.1 pstn-mbox examples 5.1 pstn-mbox examples
A pstn-mbox address in Italy for the fax service, dialled from A pstn-mbox address in Italy for the fax service, dialled from
U.S.A., using local-phone, without sub-addr-spec and without U.S.A., using local-phone, without sub-addr-spec and without
written-sep: written-sep:
FAX=0103940226338 FAX=0103940226338
A pstn-mbox address in Germany for an hypotetical XYZ service, using A pstn-mbox address in Germany for an hypothetical XYZ service, using
global-phone, with ISDN sub-addr-spec 1234 and written-sep ".": global-phone, with ISDN sub-addr-spec 1234 and written-sep ".":
XYZ=+49.81.7856345/ISUB=1234 XYZ=+49.81.7856345/ISUB=1234
A pstn-mbox address in U.S.A. for fax service, using global-phone, A pstn-mbox address in U.S.A. for fax service, using global-phone,
with T.33 sub-addr-spec 8745, with written-sep "-" and post-dial sequence with T.33 sub-addr-spec 8745, with written-sep "-" and post-dial
p1w7005393w373 sequence p1w7005393w373
FAX=+1-202-455-7622/T33S=8745/PostD=p1w7005393w373 FAX=+1-202-455-7622/T33S=8745/PostD=p1w7005393w373
A pstn-mbox address in Italy for fax service, using local-phone, A pstn-mbox address in Italy for fax service, using local-phone,
dialed from an MTA in Germany, (international access code "00", dialed from an MTA in Germany, (international access code "00", with
with ISDN subaddress 9823, with T.33 subaddress "4312" and without ISDN subaddress 9823, with T.33 subaddress "4312" and without pause
pause or written-sep: or written-sep:
FAX=003940226338/Isub=9823/T33S=4312 FAX=003940226338/Isub=9823/T33S=4312
The same pstn-mbox address in Italy, using local-phone dialed from The same pstn-mbox address in Italy, using local-phone dialed from an
an MTA in Italy (long distance call), with long distant access "0", MTA in Italy (long distance call), with long distant access "0", with
with exit-code "9", T.33 subaddress "4312", pause "p" and written-sep exit-code "9", T.33 subaddress "4312", pause "p" and written-sep ".":
".":
FAX=9p040p22.63.38/t33s=4312 FAX=9p040p22.63.38/t33s=4312
A pstn-mbox address in North America for hypotetical service XYZ, A pstn-mbox address in North America for hypothetical service XYZ,
using global-phone, without sub-addr-spec and written-sep "-" and ".": using global-phone, without sub-addr-spec and written-sep "-" and
".":
XYZ=+1.202.344-5723 XYZ=+1.202.344-5723
A pstn-mbox address for fax service in France, using local-phone A pstn-mbox address for fax service in France, using local-phone
dialed from an MTA in France (long distance call), with exit-code dialed from an MTA in France (long distance call), with exit-code
"0", T.33 subaddress "3345" and pause "p": "0", T.33 subaddress "3345" and pause "p":
FAX=0p0134782289/T33s=3345 FAX=0p0134782289/T33s=3345
A pstn-mbox address for fax service in North America, using local-phone, A pstn-mbox address for fax service in North America, using local-
without sub-addr-spec, without local-number, using only post-dial phone, without sub-addr-spec, without local-number, using only post-
sequences to reach numbers stored in a locally defined short-dial numbers dial sequences to reach numbers stored in a locally defined short-
database, where 6743 is an access password, and 99p51 is the sequence to dial numbers database, where 6743 is an access password, and 99p51 is
access the local short-dial number: the sequence to access the local short-dial number:
FAX=/postd=w6743w99p51 FAX=/postd=w6743w99p51
5.2 pstn-recipient examples 5.2 pstn-recipient examples
Here are a number of pstn-recipient examples. Please note that Here are a number of pstn-recipient examples. Please note that pstn-
pstn-recipient is just an optional element, and thus a pstn-mbox recipient is just an optional element, and thus a pstn-mbox element
element also is required in a pstn-address. also is required in a pstn-address.
A pstn-recipient using only recipient-name, with givenname initials A pstn-recipient using only recipient-name, with givenname initials
and surname: and surname:
/ATTN=Tom.J.Smiths /ATTN=Tom.J.Smiths
A pstn-recipient using only recipient-name, with givenname, a A pstn-recipient using only recipient-name, with givenname, a
complete set of initials (including the first name initial "C") and complete set of initials (including the first name initial "C") and
surname (where the "real life" givennames are "Carlo Maria Luis surname (where the "real life" givennames are "Carlo Maria Luis
Santo" and the surname is "Nascimento"): Santo" and the surname is "Nascimento"):
/ATTN=Carlo.CMLS.Nascimento /ATTN=Carlo.CMLS.Nascimento
A pstn-recipient using only recipient-name, with givenname and A pstn-recipient using only recipient-name, with givenname and
surname: surname:
/ATTN=Mark.Collins /ATTN=Mark.Collins
A pstn-recipient using only recipient-name, with surname only: A pstn-recipient using only recipient-name, with surname only:
/ATTN=Smiths /ATTN=Smiths
A pstn-recipient using recipient-name, and one recipient-qualifier A pstn-recipient using recipient-name, and one recipient-qualifier
element: element:
/ATTN=J.Smiths/OFNA=Quaility-control /ATTN=J.Smiths/OFNA=Quaility-control
A pstn-recipient using two recipient-qualifier extension, only: A pstn-recipient using two recipient-qualifier extension, only:
/OFNO=T2-33A/OFNA=Quality-Ccontrol /OFNO=T2-33A/OFNA=Quality-Ccontrol
A fax-recipient using some recipient-qualifier for physical delivery: A fax-recipient using some recipient-qualifier for physical delivery:
/STR=45, Main.Street/OFNA=Sales.dept /STR=45, Main.Street/OFNA=Sales.dept
5.3 pstn-address examples 5.3 pstn-address examples
Some pstn-address examples, obtained combining elements from Some pstn-address examples, obtained combining elements from previous
previous examples. There are complete addresses which can examples. There are complete addresses which can be used as "local
be used as "local part" (LHS) element of an e-mail address. part" (LHS) element of an e-mail address.
Without optional pstn-recipient (fax service): Without optional pstn-recipient (fax service):
FAX=+12023445723 FAX=+12023445723
With pstn-recipient (XYZ service): With pstn-recipient (XYZ service):
XYZ=+3940226338/ATTN=Mark.Collins XYZ=+3940226338/ATTN=Mark.Collins
With pstn-recipient made of two recipient-qualifier extensions With pstn-recipient made of two recipient-qualifier extensions (fax
(fax service): service):
FAX=9p040p22.63.38/t33s=4312/ofno=T2-33A/OFNA=Q-C FAX=9p040p22.63.38/t33s=4312/ofno=T2-33A/OFNA=Q-C
5.4 pstn-email examples 5.4 pstn-email examples
Here are the same addresses as before, where "faxgw" is the Here are the same addresses as before, where "faxgw" is the
mta-I-pstn field for the fax service. mta-I-pstn field for the fax service.
[email protected]
FAX=+39-40-226338/ATTN=Mark.Collins@faxgw FAX=+12023445723@faxgw
FAX=9p040p226338/T33S=4312/OFNO=T2-33A/OFNA=Q-C@faxgw FAX=+39-40-226338/ATTN=Mark.Collins@faxgw
FAX=+39040226338/ATTN=Mark.Collins/@faxgw FAX=9p040p226338/T33S=4312/OFNO=T2-33A/[email protected]
FAX=+39040226338/ATTN=Mark.Collins/@faxgw
NOTE: the optional "/" in front for the "@" sign can be generated NOTE: the optional "/" in front for the "@" sign can be generated by
by gateways to other services, like MIXER [3]. gateways to other services, like MIXER [3].
5.5 A complete SMTP transaction example: 5.5 A complete SMTP transaction example:
Here is an example of complete SMTP transaction. Here is an example of complete SMTP transaction.
S: <listening on SMTP port> S: <listening on SMTP port>
C: <opens connection to SMTP port> C: <opens connection to SMTP port>
S: 220 foo.domain.com ESMTP service ready S: 220 foo.domain.com ESMTP service ready
C: EHLO pc.mailfax.com C: EHLO pc.mailfax.com
S: 250 foo.domain.com says hello S: 250 foo.domain.com says hello
C: MAIL FROM:<[email protected]> C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> Sender ok S: 250 <[email protected]> Sender ok
C: RCPT TO:<[email protected]> C: RCPT TO:<[email protected]>
S: 250 <FAX=+3940226338> recipient ok S: 250 <FAX=+3940226338> recipient ok
C: DATA C: DATA
S: 354 Enter your data S: 354 Enter your data
C: From: Thomas Blake <[email protected]> C: From: Thomas Blake <[email protected]>
C: To: Jim Burton <[email protected]> C: To: Jim Burton <[email protected]>
C: Subject: Hello there C: Subject: Hello there
C: MIME-version: 1.0 C: MIME-version: 1.0
C: Date: Mon, 01 Sep 1997 18:14:23 -0700 C: Date: Mon, 01 Sep 1997 18:14:23 -0700
C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306 C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306
C: C:
C: This is a MIME message. It contains a C: This is a MIME message. It contains a
C: TIFF fax bodypart C: TIFF fax bodypart
C: C:
C: --16820115-1435684603#2306 C: --16820115-1435684603#2306
C: Content-Type: image/TIFF C: Content-Type: image/TIFF
C: Content-Transfer-Encoding: BASE64 C: Content-Transfer-Encoding: BASE64
C: Content-Description: FAX C: Content-Description: FAX
C: C:
C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA
C: 87AASS2999499ASDANASDF0000ASDFASDFNANN C: 87AASS2999499ASDANASDF0000ASDFASDFNANN
C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0 C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0
C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8== C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8==
C: --16820115-1435684603#2306-- C: --16820115-1435684603#2306--
C: . C: .
S: 250 Okay S: 250 Okay
C: QUIT C: QUIT
S: 221 Goodbye S: 221 Goodbye
6. Conclusion 6. Conclusion
This proposal creates a standard set of extensions for GSTN addresses, This proposal creates a standard set of extensions for GSTN
enriching the existing minimal specification [1]. The proposal requires addresses, enriching the existing minimal specification [1]. The
no changes to existing e-mail software, and allows a more detailed proposal is consistent with existing e-mail standards, but allows a
address specification, including per originator / recipient specific more detailed GSTN address specification, including per originator
elements. The IANA registration mechanism to add easily new services and/or recipient specific elements. The IANA registration mechanism
and qualifiers using the GSTN addresses is also defined. to permit the addition of new services and qualifiers using the GSTN
addresses is also provided.
7. Security Considerations 7. Security Considerations
This document specifies a means by which GSTN addresses and more This document specifies a means by which GSTN addresses and more can
can be encoded into e-mail addresses. As routing of e-mail messages be encoded into e-mail addresses. Since e-mail routing is determined
is determined by Domain Name System (DNS) information, a successful by Domain Name System (DNS) data, a successful attack to DNS could
attack on this service could force the mail path via some particular disseminate tampered information, which causes e-mail messages to be
gateway or message transfer agent where mail security can be diverted via some MTA or Gateway where the security of the software
affected by compromised software. has been compromised.
There are several means by which an attacker might be able to There are several means by which an attacker might be able to deliver
deliver incorrect mail routing information to a client. These incorrect mail routing information to a client. These include: (a)
include: (a) compromise of a DNS server, (b) generating a compromise of a DNS server, (b) generating a counterfeit response to
counterfeit response to a client's DNS query, (c) returning a client's DNS query, (c) returning incorrect "additional
incorrect "additional information" in response to an unrelated information" in response to an unrelated query. Clients SHOULD ensure
query. Clients SHOULD ensure that mail routing are based only that mail routing are based only on authoritative answers. Once DNS
on authoritative answers. Once DNS Security mechanisms [7] Security mechanisms [7] become more widely deployed, clients SHOULD
become more widely deployed, clients SHOULD employ those mechanisms employ those mechanisms to verify the authenticity and integrity of
to verify the authenticity and integrity of mail routing records. mail routing records.
Some GSTN service require dialing of private codes, like Personal Some GSTN service require dialing of private codes, like Personal
Identification Numbers, to dial a G3 fax recipient or to access Identification Numbers, to dial a G3 fax recipient or to access
special services. As e-mail addresses are transmitted without special services. As e-mail addresses are transmitted without
encoding over the MTAs transport service, this could allow encoding over the MTAs transport service, this could allow
unauthorized people to gain access to these codes when used inside unauthorized people to gain access to these codes when used inside
local-phone. More over these codes might appear in some cases in the local-phone. More over these codes might appear in some cases in the
originator / recipient addresses on cover pages delivered via offramp originator and/or recipient addresses on cover pages delivered via
gateways to G3 fax recipients. Senders SHOULD be provided methods to offramp gateways to G3 fax recipients. Senders SHOULD be provided
prevent this disclosure, like code encryption, or masquerading methods to prevent this disclosure, like code encryption, or
techniques: out-of-band communication of authorization information or masquerading techniques: out-of-band communication of authorization
use of encrypted data in special fields are the available non-standard information or use of encrypted data in special fields are the
techniques. available non-standard techniques.
8. Copyright
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis 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."
9. Appendix A: Collected ABNF Syntax 8. Appendix A: Collected ABNF Syntax
In this section we provide a summary of ABNF specifications defining both In this section we provide a summary of ABNF specifications defining
the minimal [1] and the extended elements of pstn-address. both the minimal [1] and the extended elements of pstn-address.
pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn
mta-I-pstn = domain mta-I-pstn = domain
pstn-address = pstn-mbox [ qualif-type1 ] pstn-address = pstn-mbox [ qualif-type1 ]
pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ] pstn-address =/ pstn-mbox [ pstn-recipient ] [ qualif-type1 ]
pstn-mbox = service-selector "=" global-phone pstn-mbox = service-selector "=" global-phone
skipping to change at line 698 skipping to change at page 15, line 47
printablestring = 1*( DIGIT / ALPHA / SP / printablestring = 1*( DIGIT / ALPHA / SP /
"'" / "(" / ")" / "+" / "," / "-" / "'" / "(" / ")" / "+" / "," / "-" /
"." / "/" / ":" / "=" / "?" ) "." / "/" / ":" / "=" / "?" )
10. Appendix B: IANA Considerations 10. Appendix B: IANA Considerations
As the service-selector and qualif-type1 elements values are As the service-selector and qualif-type1 elements values are
extensible ones, they MUST be registered with IANA. extensible ones, they MUST be registered with IANA.
To register a service-selector or a qualif-type1 element, the To register a service-selector or a qualif-type1 element, the
registration form templates given in B.1 and B.2 MUST be used. In registration form templates given in B.1 and B.2 MUST be used. Any
order to detail the specification, any new registration MUST refer new registration MUST fulfill the "Specification Required" criterion,
to at least one Standard Track RFC where the element is described. as defined in RFC 2434, section 2 [13]:
IANA MUST NOT accept registrations which are not supplemented by "Specification Required - Values and their meaning MUST be
a Standard Track RFC and which are not fully specified accoding to documented in an RFC or other permanent and readily available
the template forms given in B.1 and B.2. In case of need for further reference, in sufficient detail so that interoperability
consultation about accepting a new registration, IANA SHOULD refer between independent implementations is possible."
to the Application Area Director to be directed to the approrpiate
"expert" individal or IETF Working Group.
After succesful registration, IANA should publish the registered new IANA MUST NOT accept registrations which are not supplemented by a
element in the appropriate on-line IANA WEB site, and include it Specification as defined above and which are not fully specified
into the updates of the "Assigned Numbers" RFC series. according to the template forms given in B.1 and B.2. In case of need
for further consultation about accepting a new registration, IANA
SHOULD refer to the Application Area Director to be directed to the
appropriate "expert" individual or IETF Working Group.
B.1: IANA Registration form template for new values of GSTN After successful registration, IANA should publish the registered new
address service-selector element in the appropriate on-line IANA WEB site, and include it into
the updates of the "Assigned Numbers" RFC series.
B.1: IANA Registration form template for new values of GSTN address
service-selector
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
service-selector specifier "foo" service-selector specifier "foo"
service-selector name: service-selector name:
foo foo
Description of Use: Description of Use:
foo - ("foo" is a fictional new service-selector used in this foo - ("foo" is a fictional new service-selector used in this
template as an example, it is to be replaced with the new value template as an example, it is to be replaced with the new value
being registered. Include a short description of the use of the being registered. Include a short description of the use of the
new value here. This MUST include reference to Standard Track RFCs new value here. This MUST include reference to Standard Track RFCs
and eventaully to other Standard Bodies documents for the complete and eventually to other Standard Bodies documents for the complete
description; the use of the value must be defined completely description; the use of the value must be defined completely
enough for independent implementation). enough for independent implementation).
Security Considerations: Security Considerations:
(Any additional security considerations that may be introduced by (Any additional security considerations that may be introduced by
use of the new service-selector parameter should be defined here or use of the new service-selector parameter should be defined here
in the reference Standards Track RFCs) or in the reference Standards Track RFCs)
Person & email address to contact for further information: Person & email address to contact for further information:
(fill in contact information) (fill in contact information)
INFORMATION TO THE SUBMITTER: INFORMATION TO THE SUBMITTER:
The accepted registrations will be listed in the "Assigned Numbers" The accepted registrations will be listed in the "Assigned Numbers"
series of RFCs. The information in the registration form is freely series of RFCs. The information in the registration form is freely
distributable. distributable.
skipping to change at line 777 skipping to change at page 17, line 38
non-basic tokens any already registered non-basic token from other non-basic tokens any already registered non-basic token from other
qualif-type1 elements, i.e. it MUST use the same non-basic token qualif-type1 elements, i.e. it MUST use the same non-basic token
name and then repeat its identical ABNF definition from basic name and then repeat its identical ABNF definition from basic
tokens; see appendix E for examples). tokens; see appendix E for examples).
Description of Use: Description of Use:
bar - ("bar" is a fictional description for a new qualif-type1 bar - ("bar" is a fictional description for a new qualif-type1
element used in this template as an example. It is to be replaced element used in this template as an example. It is to be replaced
by the real description of qualif-type1 element being registered. by the real description of qualif-type1 element being registered.
Include a short description of the use of the new qualif-type1 here. Include a short description of the use of the new qualif-type1
This MUST include reference to Standards Track RFCs and eventually here. This MUST include reference to Standards Track RFCs and
to other Standard Bodies documents for the complete description; the eventually to other Standard Bodies documents for the complete
use of the value MUST be defined completely enough for independent description; the use of the value MUST be defined completely
implementation.) enough for independent implementation.)
Use Restriction: Use Restriction:
(If the new qualif-type1 elements is meaningful only for a specific (If the new qualif-type1 elements is meaningful only for a
set of service-element, you MUST specify here the list of allowed specific set of service-element, you MUST specify here the list of
service-element types. If there is no restriction, then specify the allowed service-element types. If there is no restriction, then
keyword "none") specify the keyword "none")
Security Considerations: Security Considerations:
(Any additional security considerations that may be introduced by (Any additional security considerations that may be introduced by
use of the new service-selector parameter should be defined here or use of the new service-selector parameter should be defined here
in the reference Standards Track RFCs) or in the reference Standards Track RFCs)
Person & email address to contact for further information: Person & email address to contact for further information:
(fill in contact information) (fill in contact information)
INFORMATION TO THE SUBMITTER: INFORMATION TO THE SUBMITTER:
The accepted registrations will be listed in the "Assigned Numbers" The accepted registrations will be listed in the "Assigned Numbers"
series of RFCs. The information in the registration form is freely series of RFCs. The information in the registration form is freely
distributable. distributable.
skipping to change at line 822 skipping to change at page 18, line 37
service-selector name: service-selector name:
FAX FAX
Description of Use: Description of Use:
FAX - specify that the GSTN address refers either to an FAX - specify that the GSTN address refers either to an
Internet Fax device, or an onramp/offramp Fax gateway. Internet Fax device, or an onramp/offramp Fax gateway.
For a complete description refer to RFC2304 and RFC2303 For a complete description refer to RFC 2304 and RFC 2303
Security Considerations: Security Considerations:
See the Security Consideration section of RFC2304. See the Security Consideration section of RFC 2304.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
12. Appendix D: IANA Registration forms for new values of GSTN 12. Appendix D: IANA Registration forms for new values of GSTN
address qualit-type1 keyword and value address qualit-type1 keyword and value
D.1 - T33S D.1 - T33S
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "T33S" qualif-type1 element "T33S"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
T33S T33S
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
sub-addr = 1*( DIGIT ) sub-addr = 1*( DIGIT )
Description of Use: Description of Use:
T33S is used to specify the numeric only optional fax sub-address T33S is used to specify the numeric only optional fax sub-address
element described in "ITU T.33 - Facsimile routing utilizing the element described in "ITU T.33 - Facsimile routing utilizing the
subaddress; recommendation T.33 (July, 1996)". Further detailed subaddress; recommendation T.33 (July, 1996)". Further detailed
description is available in RFC2304. description is available in RFC 2304.
Use Restriction: Use Restriction:
The use of "T33S" is restricted to "FAX" service-selector, is it has The use of "T33S" is restricted to "FAX" service-selector, is it
no meaning outside the fax service. has no meaning outside the fax service.
Security Considerations: Security Considerations:
See the Security Consideration section of RFC2304. See the Security Consideration section of RFC 2304.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.2 - ISUB D.2 - ISUB
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ISUB" qualif-type1 element "ISUB"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ISUB ISUB
skipping to change at line 911 skipping to change at page 20, line 32
isub-addr = 1*( DIGIT ) isub-addr = 1*( DIGIT )
isub-addr =/ 1*( DIGIT / written-sep ) isub-addr =/ 1*( DIGIT / written-sep )
written-sep = ( "-" / "." ) written-sep = ( "-" / "." )
Description of Use: Description of Use:
"ISUB" is used to specify the optional ISDN sub-address elements used "ISUB" is used to specify the optional ISDN sub-address elements used
in ISDN service to reach specific objects on the ISDN service. It can in ISDN service to reach specific objects on the ISDN service. It can
eventually embed written separator elemens for the only scope to eventually embed written separator elements for the only scope to
enhance human readability. See <this RFC> for further details. enhance human readability. See RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.3 - POSTD D.3 - POSTD
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "POSTD" qualif-type1 element "POSTD"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
POSTD POSTD
skipping to change at line 961 skipping to change at page 21, line 45
pause = "p" pause = "p"
tonewait = "w" tonewait = "w"
written-sep = ( "-" / "." ) written-sep = ( "-" / "." )
Description of Use: Description of Use:
POSTD is the optional further dialling sequence needed to access POSTD is the optional further dialling sequence needed to access
additional services (for example a menu' driven interface) available additional services (for example a menu' driven interface)
after the service site has been accessed using gstn-phone. See available after the service site has been accessed using
<this RFC> for further details. gstn-phone. See RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.4 - ATTN D.4 - ATTN
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ATTN" qualif-type1 element "ATTN"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ATTN ATTN
skipping to change at line 1015 skipping to change at page 23, line 8
initials = 1*ALPHA initials = 1*ALPHA
printablestring = 1*( DIGIT / ALPHA / SP / printablestring = 1*( DIGIT / ALPHA / SP /
"'" / "(" / ")" / "+" / "," / "-" / "'" / "(" / ")" / "+" / "," / "-" /
"." / "/" / ":" / "=" / "?" ) "." / "/" / ":" / "=" / "?" )
Description of Use: Description of Use:
To specify the personal name of the individual intended as the To specify the personal name of the individual intended as the
originator or the recipient of the message. See <this RFC> for originator or the recipient of the message. See RFC 2846 for
further details. further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.5 - ORG D.5 - ORG
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ORG" qualif-type1 element "ORG"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ORG ORG
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Organization Name (example: ACME Inc.) See <this RFC> To specify the Organization Name (example: ACME Inc.) See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.6 - OFNO D.6 - OFNO
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "OFNO" qualif-type1 element "OFNO"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
OFNO OFNO
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Office Number (example: BLD2-44) See <this RFC> To specify the Office Number (example: BLD2-44) See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.7 - OFNA D.7 - OFNA
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "OFNA" qualif-type1 element "OFNA"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
OFNA OFNA
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Office Name (example: Sales) See <this RFC> To specify the Office Name (example: Sales) See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.8 - STR D.8 - STR
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "STR" qualif-type1 element "STR"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
STR STR
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Street Address (example: 45, Main Street). To specify the Street Address (example: 45, Main Street).
See <this RFC> for further details. See RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.9 - ADDR D.9 - ADDR
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ADDR" qualif-type1 element "ADDR"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ADDR ADDR
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Unformatted Postal Address (example: HWY 14, To specify the Unformatted Postal Address (example: HWY 14,
Km 94.5 - Loc. Redhill). See <this RFC> for further details. Km 94.5 - Loc. Redhill). See RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.10 - ADDU D.10 - ADDU
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ADDU" qualif-type1 element "ADDU"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ADDU ADDU
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Unique Postal Name (example: ACMETELEX). See To specify the Unique Postal Name (example: ACMETELEX). See
<this RFC> for further details. RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.11 - ADDL D.11 - ADDL
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ADDL" qualif-type1 element "ADDL"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ADDL ADDL
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Local Postal Attributes (example: Entrance 3, To specify the Local Postal Attributes (example: Entrance 3,
3rd floor, Suite 296). See <this RFC> for further details. 3rd floor, Suite 296). See RFC 2846 for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.12 - POB D.12 - POB
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "POB" qualif-type1 element "POB"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
POB POB
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Post Office Box (example: CP 1374). See <this RFC> To specify the Post Office Box (example: CP 1374). See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.13 - ZIP D.13 - ZIP
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "ZIP" qualif-type1 element "ZIP"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
ZIP ZIP
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify Postal ZIP code (example: I 34012). See <this RFC> To specify Postal ZIP code (example: I 34012). See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
D.14 - CO D.14 - CO
To: [email protected] To: [email protected]
Subject: Registration of new values for the GSTN address Subject: Registration of new values for the GSTN address
qualif-type1 element "CO" qualif-type1 element "CO"
qualif-type1 "keyword" name: qualif-type1 "keyword" name:
CO CO
qualif-type1 "value" ABNF definition: qualif-type1 "value" ABNF definition:
string = PCHAR string = PCHAR
Description of Use: Description of Use:
To specify the Country Name (example: Belgium) See <this RFC> To specify the Country Name (example: Belgium) See RFC 2846
for further details. for further details.
Use Restriction: Use Restriction:
none. none.
Security Considerations: Security Considerations:
See the Security Consideration section of <this RFC>. See the Security Consideration section of RFC 2846.
Person & email address to contact for further information: Person & email address to contact for further information:
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
13. Author's Address 13. Author's Address
Claudio Allocchio Claudio Allocchio
Sincrotrone Trieste INFN-GARR
c/o Sincrotrone Trieste
SS 14 Km 163.5 Basovizza SS 14 Km 163.5 Basovizza
I 34012 Trieste I 34012 Trieste
Italy Italy
RFC822: [email protected] RFC822: [email protected]
X.400: C=it;A=garr;P=Trieste;O=Elettra; X.400: C=it;A=garr;P=Trieste;O=Elettra;
S=Allocchio;G=Claudio; S=Allocchio;G=Claudio;
Phone: +39 40 3758523 Phone: +39 040 3758523
Fax: +39 40 3758565 Fax: +39 040 3758565
14. References 14. References
[1] Allocchio, C., "Minimal PSTN address format in Internet Mail", [1] Allocchio, C., "Minimal PSTN address format in Internet Mail",
RFC 2303, March 1998. RFC 2303, March 1998.
[2] Allocchio, C., "Minimal FAX address format in Internet Mail", [2] Allocchio, C., "Minimal FAX address format in Internet Mail",
RFC 2304, March 1998. RFC 2304, March 1998.
[3] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping [3] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998. between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications", RFC 2234, November 1997. Specifications", RFC 2234, November 1997.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT): [6] ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT):
Access Devices Dual Tone Multi Frequency (DTMF) sender for acoustical Access Devices Dual Tone Multi Frequency (DTMF) sender for
coupling to the microphone of a handset telephone (March 1995) acoustical coupling to the microphone of a handset telephone
(March 1995)
[7] ITU E.164 - Numbering plan for the ISDN era; recommendation [7] ITU E.164 - The International Public Telecommunication Numbering
E.164/I.331 (August 1991) Plan E.164/I.331 (May 1997)
[8] ITU T.33 - Facsimile routing utilizing the subaddress; recommendation [8] ITU T.33 - Facsimile routing utilizing the subaddress;
T.33 (July, 1996) recommendation T.33 (July, 1996)
[9] ITU F.401 - Message Handling Services: Naming and Addressing for [9] ITU F.401 - Message Handling Services: Naming and Addressing for
Public Massage Handling Service; reccommendation F.401 (August 1992) Public Massage Handling Service; recommendation F.401 (August
1992)
[10] ITU F.423 - Message Handling Services: Intercommunication Between [10] ITU F.423 - Message Handling Services: Intercommunication
the Interpersonal Messaging Service and the Telefax Service; Between the Interpersonal Messaging Service and the Telefax
reccommendation F.423 (August 1992) Service; recommendation F.423 (August 1992)
[11] Crocker, D., " Standard for the format of ARPA Internet text [11] Crocker, D., "Standard for the format of ARPA Internet text
messages", STD 11, RFC 822, August 1982. messages", STD 11, RFC 822, August 1982.
[12] Braden, R., "Requirements for Internet hosts - application and [12] Braden, R., "Requirements for Internet hosts - application and
support", RFC 1123, October 1989. support", STD 3, RFC 1123, October 1989.
[13] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
15. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 181 change blocks. 
445 lines changed or deleted 469 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/