< 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.
	FAX=+12023445723@faxgw
	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/OFNA=Q-C@faxgw
			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:<tom@mailfax.com>		C: MAIL FROM:<tom@mailfax.com>
	S: 250 <tom@mailfax.com> Sender ok		S: 250 <tom@mailfax.com> Sender ok
	C: RCPT TO:<FAX=+3940226338@foo.mailfax.com>		C: RCPT TO:<FAX=+3940226338@foo.mailfax.com>
	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 <tom@mailfax.com>		C: From: Thomas Blake <tom@mailfax.com>
	C: To: Jim Burton <FAX=+3940226338@foo.mailfax.com>		C: To: Jim Burton <FAX=+3940226338@foo.mailfax.com>
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: IANA@isi.edu		To: IANA@isi.edu
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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: Claudio.Allocchio@elettra.trieste.it		RFC822: Claudio.Allocchio@elettra.trieste.it
	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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/