< draft-ietf-fax-fulladdr-04.txt		draft-ietf-fax-fulladdr-05.txt >
	Network Working C. Allocchio		Network Working C. Allocchio
	Group GARR-Italy		Group GARR-Italy
	INTERNET-DRAFT September 1998		INTERNET-DRAFT February 1999
	Expires: March 1999		Expires: August 1999
	File: draft-ietf-fax-fulladdr-04.txt		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. Internet Drafts are working		This document is an Internet Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its Areas,		all provisions of Section 10 of RFC2026.
	and its Working Groups. Note that other groups may also distribute
	working documents as Internet Drafts. Internet Drafts are draft		Internet-Drafts are working documents of the Internet Engineering
	documents valid for a maximum of six months. Internet Drafts may be		Task Force (IETF), its areas, and its working groups. Note that
	updated, replaced, or obsoleted by other documents at any time. It is		other groups may also distribute working documents as Internet-Drafts.
	not appropriate to use Internet Drafts as reference material or to
	cite them other than as a "working draft" or "work in progress".		Internet-Drafts are draft documents valid for a maximum of six
	Please check the I-D abstract listing contained in each Internet Draft		months and may be updated, replaced, or obsoleted by other documents
	directory to learn the current status of this or any other Internet		at any time. It is inappropriate to use Internet-Drafts as
	Draft.		reference material or to cite them other than as "work in progress."
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
	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" (formerly known also as 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: the minimal format and general
	address syntax are defined in [1], together with the syntax to define		address syntax are defined in [1], together with the syntax to define
	additional address elements.		additional address elements.
	To ensure interoperability among different applications, also the		To ensure interoperability among different applications, also the
	additional, and in most cases optional, address elements must be		additional, and in most cases optional, address elements must be
	defined in a standard syntax. In this memo we define some of these		defined in a standard syntax. In this memo we define some of these
	additional address elements:		additional address elements:
	skipping to change at line 53 ¶		skipping to change at line 59 ¶
	The definitions included in this memo always superset the minimal		The definitions included in this memo always superset the minimal
	profile defined in [1]. The "incremental alternatives" syntax defined		profile defined in [1]. The "incremental alternatives" syntax defined
	in [4] is used to describe this fact.		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 in
	other specifications (see for example "T33S" element in [2]), but		other specifications (see for example "T33S" element in [2]), but
	they MUST use definitions contained in this memo for those elements		they MUST use definitions contained in this memo for those elements
	already specified here.		already specified here.
			In particular, "service-selector" names and "qualif-type1" elements
			MUST be registered with IANA, and published within the "ASSIGNED
			NUMBERS" document. This will ensure an easy mechanism for extending
			the element sets and will avoid unecessary duplication. IANA
			Registration form templates are provided in Appendix B.
			A collection of forms for already defined "serivce-selector" and
			"qualif-type1" elements is listed in appendix C and appendix D
			respectively. Standard Track RFC specification MUST supplement the
			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		Even if in this memo we focus on e-mail addresses, a number of elements
	defined in this specification can also be used for other specifications		defined in this specification can also be used for other specifications
	dealing with embedding GSTN addresses into other addresses: for example		dealing with embedding GSTN addresses into other addresses: for example
	there is some work in progress about URLs specification which adopts		there is some work in progress about URLs specification which adopts
	similar definitions, with slight changes in the global syntax due to		similar definitions, with slight changes in the global syntax due to
	specific URL format.		specific URL format.
	Finally, in this memo we try to maintain maximum compatibility		Finally, in this memo we try to maintain maximum compatibility
	with existing e-mail gateway services and standard specifications.		with existing e-mail gateway services and standard specifications.
	In particular we will use as much as possible compatible definitions		In particular we will use as much as possible compatible definitions
	skipping to change at line 168 ¶		skipping to change at line 186 ¶
	[7], which apply to all possible services, while other types are		[7], which apply to all possible services, while other types are
	limited to specific services (see the fax service T.33 subaddress [8],		limited to specific services (see the fax service T.33 subaddress [8],
	[2]).		[2]).
	We must thus be able to specify at least the ISDN subaddress, remembering		We must thus be able to specify at least the ISDN subaddress, remembering
	that an ISDN subaddress could be supplemented by other subaddress types		that an ISDN subaddress could be supplemented by other subaddress types
	(like a fax T.33 [8] subaddress).		(like a fax T.33 [8] subaddress).
	As a consequence, the definition of sub-addr-spec is:		As a consequence, the definition of sub-addr-spec is:
	sub-addr-spec = [ isdn-sep sub-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
	sub-addr = 1*( DIGIT )		isub-addr = 1*( DIGIT )
	sub-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
	2.3 The post-dial element		2.3 The post-dial element
	In some cases, after the connection with the destination GSTN		In some cases, after the connection with the destination GSTN
	device has been established, a further dialling sequence can be		device has been established, a further dialling sequence can be
	required to access further services; a typical example are the		required to access further services; a typical example are the
	automated menu-driven services using DTMF sequences on the		automated menu-driven services using DTMF sequences on the
	telephone services. These sequences are defined as a separator		telephone services. These sequences are defined as a separator
	and a post dial sequence:		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		A number of gstn-phone examples are listed in section 4.
			The IANA registration form for post-sep and post-dial are given in
			appendix D.3
	3. The pstn-recipient		3. The pstn-recipient
	The pstn-mbox element is sometimes not enough to specify additional		The pstn-mbox element is sometimes not enough to specify additional
	Details, like the originator / recipient name, physical address, etc.		Details, like the originator / recipient name, physical address, etc.
	The optional pstn-recipient element provides information which could		The optional pstn-recipient element provides information which could
	also be used by the onramp / offramp gateway to specify the originator /		also be used by the onramp / offramp gateway to specify the originator /
	recipient exactly. In many cases the pstn-recipient element will be		recipient exactly. In many cases the pstn-recipient element will be
	used for recipient addresses: however also originator addresses could		used for recipient addresses: however also originator addresses could
	be specified using pstn-mbox and pstn-recipient, in particular if onramp		be specified using pstn-mbox and pstn-recipient, in particular if onramp
	skipping to change at line 232 ¶		skipping to change at line 255 ¶
	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 ]
	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:		recipient:
	recipient-name = "/ATTN="		recipient-name = "/ATTN=" pers-name
	[ givenname "." ]
	[ initials "." ]		pers-name = [ givenname "." ]
	surname		[ initials "." ]
			surname
	The following definitions come directly from MIXER specification [3]:		The following definitions come directly from 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: the "initials" element does not simply specify the
	middle initial which is common in some countries; it		middle initial which is common in some countries; it
	allows the complete set of givennames initials in any		allows the complete set of givennames initials in any
	possible combination. See examples at section 5.2		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 "pstn-address" element (in all its
	components and extensions) MUST strictly follow the "quoting rules"		components and extensions) MUST strictly follow the "quoting rules"
	spcified in the relevant standards [11], [12].		spcified in the relevant standards [11], [12].
			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. A set of elements is thus defined:		originator / recipient. An additional set of optional elements, whose
			specific definition is in most cases application dependent, is 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 qualif-type1 element in a recursive definition which allows an		a qualif-type1 element in a recursive definition which allows an
	extensible format. However we define at least a number of these		extensible format. However we define at least a number of these
	elements, calling them "qualif-type2"		elements, calling them "qualif-type2"
	qualif-type2 = "/" qual2-label "=" string		qualif-type2 = "/" qual2-label "=" string
	skipping to change at line 302 ¶		skipping to change at line 330 ¶
	"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)
	"ADDU" Unique postal name for physical delivery (example:		"ADDU" Unique postal name for physical delivery (example:
	ACMETELEX)		ACMETELEX)
	"ADDL" Local postal attrobutes 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
	-----------------------------------------------------------------		-----------------------------------------------------------------
	The above elements are usually enough to exactly specify the		One or a combination of some of the above elements are usually enough
	originator / recipient of the message.		to exactly specify the originator / recipient of the message. The use
			of a large number of these elements could in fact create a very long
			recipient-qualifier. Thus only the strictly needed elements SHOULD
			be used. The maximum total length of the pstn-email MUST in fact
			not exceed the limits specified in the relevant standards [11] [12].
	IMPORTANT NOTE: even if the meaning of the above elements is derived		IMPORTANT NOTE: even if 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		their names is explicitly different, in order not to conflict with
	specific X.400 addressing rules. Also any additional qualif-type1		specific X.400 addressing rules. Also any additional qualif-type1
	element defined in different specification SHOULD use different		element defined in different specification SHOULD use different
	label names to avoid possible conflicts.		label names to avoid possible conflicts.
			The IANA registration form for these elements is given in appendix
			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		In case there are multiple sub-addr-spec to be given on the same
	pstn-mbox then multiple pstn-email elements will be used. The UA could		pstn-mbox then multiple pstn-email elements will be used. The UA could
	accept multiple sub-addr-spec elements for the same global-phone /		accept multiple sub-addr-spec elements for the same global-phone /
	local-phone, but it MUST generate multiple pstn-mbox, when passing the		local-phone, but it MUST generate multiple pstn-mbox, when passing the
	message to the MTA.		message to the MTA.
	5. Examples		5. Examples
	skipping to change at line 425 ¶		skipping to change at line 460 ¶
	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-quelifier 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 examples. There are complete addresses which can		previous examples. There are complete addresses which can
	be used as "local part" (LHS) element of an e-mail address.		be used as "local part" (LHS) element of an e-mail address.
	Without optional pstn-recipient (fax service):		Without optional pstn-recipient (fax service):
	skipping to change at line 491 ¶		skipping to change at line 526 ¶
	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-Tranfer-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 addresses,
	enriching the existig minimal specification [1]. The proposal requires		enriching the existing minimal specification [1]. The proposal requires
	no changes to existing e-mail software, and allows a more detailed		no changes to existing e-mail software, and allows a more detailed
	address specification, including per originator / recipient specific		address specification, including per originator / recipient specific
	elements.		elements. The IANA registration mechanism to add easily new services
			and qualifiers using the GSTN addresses is also defined.
	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 be encoded into e-mail addresses. As routing of e-mail messages		can be encoded into e-mail addresses. As routing of e-mail messages
	is determined by Domain Name System (DNS) information, a succesful		is determined by Domain Name System (DNS) information, a successful
	attack on this service could force the mail path via some particular		attack on this service could force the mail path via some particular
	gateway or message transfer agent where mail security can be		gateway or message transfer agent where mail security can be
	affected by compromised software.		affected by compromised software.
	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 incorrect mail routing information to a client. These		deliver incorrect mail routing information to a client. These
	include: (a) compromise of a DNS server, (b) generating a		include: (a) compromise of a DNS server, (b) generating a
	counterfeit response to a client's DNS query, (c) returning		counterfeit response to a client's DNS query, (c) returning
	incorrect "additional information" in response to an unrelated		incorrect "additional information" in response to an unrelated
	query. Clients SHOULD ensure that mail routing are based only		query. Clients SHOULD ensure that mail routing are based only
	on authoritative answers. Once DNS Security mechanisms [7]		on authoritative answers. Once DNS Security mechanisms [7]
	become more widely deployed, clients SHOULD employ those mechanisms		become more widely deployed, clients SHOULD employ those mechanisms
	to verify the authenticity and integrity of mail routing records.		to verify the authenticity and integrity of 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 access special services. As e-mail		Identification Numbers, to dial a G3 fax recipient or to access
	addresses are transmitted without encoding over the MTAs transport		special services. As e-mail addresses are transmitted without
	service, this could allow unauthorized people to gain access to		encoding over the MTAs transport service, this could allow
	these codes when used inside local-phone. Use of double key		unauthorized people to gain access to these codes when used inside
	encryption techniques for local-phone can solve these security		local-phone. More over these codes might appear in some cases in the
	problem.		originator / recipient addresses on cover pages delivered via offramp
			gateways to G3 fax recipients. Senders SHOULD be provided methods to
			prevent this disclosure, like code encryption, or masquerading
			techniques: out-of-band communication of authorization information or
			use of encrypted data in special fields are the available non-standard
			techniques.
	8. Copyright		8. Copyright
	"Copyright (C) The Internet Society (date). All Rights Reserved.		"Copyright (C) The Internet Society (date). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implmentation may be prepared, copied, published and		or assist in its implmentation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are		provided that the above copyright notice and this paragraph are
	skipping to change at line 566 ¶		skipping to change at line 607 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL		NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
	NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR		NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
	FITNESS FOR A PARTICULAR PURPOSE."		FITNESS FOR A PARTICULAR PURPOSE."
	9. Appendix: Collected ABNF Syntax		9. 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 both
	the minimal [1] and the extended elements of pstn-address.		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 ]
	skipping to change at line 612 ¶		skipping to change at line 653 ¶
	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" )
	written-sep = ( "-" / "." )		written-sep = ( "-" / "." )
	pause = "p"		pause = "p"
	tonewait = "w"		tonewait = "w"
	sub-addr-spec = [ isdn-sep sub-addr ]		sub-addr-spec = [ isdn-sep isub-addr ]
	isdn-sep = "/ISUB="		isdn-sep = "/ISUB="
	sub-addr = 1*( DIGIT )		isub-addr = 1*( DIGIT )
	sub-addr =/ 1*( DIGIT / written-sep )		isub-addr =/ 1*( DIGIT / written-sep )
	post-sep = "/POSTD="		post-sep = "/POSTD="
	post-dial = phone-string		post-dial = phone-string
	pstn-recipient = [ recipient-name ]		pstn-recipient = [ recipient-name ]
	[ 1*( recipient-qualifier ) ]		[ 1*( recipient-qualifier ) ]
	recipient-name = "/ATTN="		recipient-name = "/ATTN=" pers-name
	[ givenname "." ]
	[ initials "." ]		pers-name = [ givenname "." ]
	surname		[ initials "." ]
			surname
	surname = printablestring		surname = printablestring
	givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" /		givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" /
	"," / "-" / "/" / ":" / "=" / "?" )		"," / "-" / "/" / ":" / "=" / "?" )
	initials = 1*ALPHA		initials = 1*ALPHA
	recipient-qualifier = ( qualif-type1 / qualif-type2 )		recipient-qualifier = ( qualif-type1 / qualif-type2 )
	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"
	printablestring = 1*( DIGIT / ALPHA / SP /		printablestring = 1*( DIGIT / ALPHA / SP /
	"'" / "(" / ")" / "+" / "," / "-" /		"'" / "(" / ")" / "+" / "," / "-" /
	"." / "/" / ":" / "=" / "?" )		"." / "/" / ":" / "=" / "?" )
	10. Author's Address		10. Appendix B: IANA Considerations
			As the service-selector and qualif-type1 elements values are
			extensible ones, they MUST be registered with IANA.
			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
			order to detail the specification, any new registration MUST refer
			to at least one Standard Track RFC where the element is described.
			IANA MUST NOT accept registrations which are not supplemented by
			a Standard Track RFC and which are not fully specified accoding 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 approrpiate
			"expert" individal or IETF Working Group.
			After succesful registration, IANA should publish the registered new
			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
			Subject: Registration of new values for the GSTN address
			service-selector specifier "foo"
			service-selector name:
			foo
			Description of Use:
			foo - ("foo" is a fictional new service-selector used in this
			template as an example, it is to be replaced with the new value
			being registered. Include a short description of the use of the
			new value here. This MUST include reference to Standard Track RFCs
			and eventaully to other Standard Bodies documents for the complete
			description; the use of the value must be defined completely
			enough for independent implementation).
			Security Considerations:
			(Any additional security considerations that may be introduced by
			use of the new service-selector parameter should be defined here or
			in the reference Standards Track RFCs)
			Person & email address to contact for further information:
			(fill in contact information)
			INFORMATION TO THE SUBMITTER:
			The accepted registrations will be listed in the "Assigned Numbers"
			series of RFCs. The information in the registration form is freely
			distributable.
			B.2: IANA Registration form template for new values of GSTN
			address qualif-type1 keyword and value
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "bar"
			qualif-type1 "keyword" name:
			bar
			qualif-type1 "value" ABNF definition:
			abnf - ("abnf" MUST define the ABNF form of the qualif-type1 value.
			The ABNF specification MUST be self-contained, using as basic
			elements the tokens given in specification [4]. To avoid any
			duplication (when appropriate), it MUST also use as building
			non-basic tokens any already registered non-basic token from other
			qualif-type1 elements, i.e. it MUST use the same non-basic token
			name and then repeat its identical ABNF definition from basic
			tokens; see appendix E for examples).
			Description of Use:
			bar - ("bar" is a fictional description for a new qualif-type1
			element used in this template as an example. It is to be replaced
			by the real description of qualif-type1 element being registered.
			Include a short description of the use of the new qualif-type1 here.
			This MUST include reference to Standards Track RFCs and eventually
			to other Standard Bodies documents for the complete description; the
			use of the value MUST be defined completely enough for independent
			implementation.)
			Use Restriction:
			(If the new qualif-type1 elements is meaningful only for a specific
			set of service-element, you MUST specify here the list of allowed
			service-element types. If there is no restriction, then specify the
			keyword "none")
			Security Considerations:
			(Any additional security considerations that may be introduced by
			use of the new service-selector parameter should be defined here or
			in the reference Standards Track RFCs)
			Person & email address to contact for further information:
			(fill in contact information)
			INFORMATION TO THE SUBMITTER:
			The accepted registrations will be listed in the "Assigned Numbers"
			series of RFCs. The information in the registration form is freely
			distributable.
			11. Appendix C: IANA Registration form for new value of GSTN
			address service-selector "FAX"
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			service-selector specifier "FAX"
			service-selector name:
			FAX
			Description of Use:
			FAX - specify that the GSTN address refers either to an
			Internet Fax device, or an onramp/offramp Fax gateway.
			For a complete description refer to RFC2304 and RFC2303
			Security Considerations:
			See the Security Consideration section of RFC2304.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			12. Appendix D: IANA Registration forms for new values of GSTN
			address qualit-type1 keyword and value
			D.1 - T33S
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "T33S"
			qualif-type1 "keyword" name:
			T33S
			qualif-type1 "value" ABNF definition:
			sub-addr = 1*( DIGIT )
			Description of Use:
			T33S is used to specify the numeric only optional fax sub-address
			element described in "ITU T.33 - Facsimile routing utilizing the
			subaddress; recommendation T.33 (July, 1996)". Further detailed
			description is available in RFC2304.
			Use Restriction:
			The use of "T33S" is restricted to "FAX" service-selector, is it has
			no meaning outside the fax service.
			Security Considerations:
			See the Security Consideration section of RFC2304.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.2 - ISUB
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ISUB"
			qualif-type1 "keyword" name:
			ISUB
			qualif-type1 "value" ABNF definition:
			isub-addr = 1*( DIGIT )
			isub-addr =/ 1*( DIGIT / written-sep )
			written-sep = ( "-" / "." )
			Description of Use:
			"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
			eventually embed written separator elemens for the only scope to
			enhance human readability. See <this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.3 - POSTD
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "POSTD"
			qualif-type1 "keyword" name:
			POSTD
			qualif-type1 "value" ABNF definition:
			phone-string = 1*( DTMF / pause / tonewait / written-sep )
			DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" )
			pause = "p"
			tonewait = "w"
			written-sep = ( "-" / "." )
			Description of Use:
			POSTD is the optional further dialling sequence needed to access
			additional services (for example a menu' driven interface) available
			after the service site has been accessed using gstn-phone. See
			<this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.4 - ATTN
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ATTN"
			qualif-type1 "keyword" name:
			ATTN
			qualif-type1 "value" ABNF definition:
			pers-name = [ givenname "." ] [ initials "." ] surname
			surname = printablestring
			givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" /
			"," / "-" / "/" / ":" / "=" / "?" )
			initials = 1*ALPHA
			printablestring = 1*( DIGIT / ALPHA / SP /
			"'" / "(" / ")" / "+" / "," / "-" /
			"." / "/" / ":" / "=" / "?" )
			Description of Use:
			To specify the personal name of the individual intended as the
			originator or the recipient of the message. See <this RFC> for
			further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.5 - ORG
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ORG"
			qualif-type1 "keyword" name:
			ORG
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Organization Name (example: ACME Inc.) See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.6 - OFNO
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "OFNO"
			qualif-type1 "keyword" name:
			OFNO
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Office Number (example: BLD2-44) See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.7 - OFNA
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "OFNA"
			qualif-type1 "keyword" name:
			OFNA
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Office Name (example: Sales) See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.8 - STR
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "STR"
			qualif-type1 "keyword" name:
			STR
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Street Address (example: 45, Main Street).
			See <this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.9 - ADDR
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ADDR"
			qualif-type1 "keyword" name:
			ADDR
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Unformatted Postal Address (example: HWY 14,
			Km 94.5 - Loc. Redhill). See <this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.10 - ADDU
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ADDU"
			qualif-type1 "keyword" name:
			ADDU
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Unique Postal Name (example: ACMETELEX). See
			<this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.11 - ADDL
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ADDL"
			qualif-type1 "keyword" name:
			ADDL
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Local Postal Attributes (example: Entrance 3,
			3rd floor, Suite 296). See <this RFC> for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.12 - POB
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "POB"
			qualif-type1 "keyword" name:
			POB
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Post Office Box (example: CP 1374). See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.13 - ZIP
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "ZIP"
			qualif-type1 "keyword" name:
			ZIP
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify Postal ZIP code (example: I 34012). See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			D.14 - CO
			To: IANA@isi.edu
			Subject: Registration of new values for the GSTN address
			qualif-type1 element "CO"
			qualif-type1 "keyword" name:
			CO
			qualif-type1 "value" ABNF definition:
			string = PCHAR
			Description of Use:
			To specify the Country Name (example: Belgium) See <this RFC>
			for further details.
			Use Restriction:
			none.
			Security Considerations:
			See the Security Consideration section of <this RFC>.
			Person & email address to contact for further information:
			Claudio Allocchio
			Sincrotrone Trieste
			SS 14 Km 163.5 Basovizza
			I 34012 Trieste
			Italy
			RFC822: Claudio.Allocchio@elettra.trieste.it
			X.400: C=it;A=garr;P=Trieste;O=Elettra;
			S=Allocchio;G=Claudio;
			Phone: +39 40 3758523
			Fax: +39 40 3758565
			13. Author's Address
	Claudio Allocchio		Claudio Allocchio
	Sincrotrone Trieste		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 40 3758523
	Fax: +39 40 3758565		Fax: +39 40 3758565
	11. 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.
End of changes. 27 change blocks.
	49 lines changed or deleted		849 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/