< draft-ietf-fax-faxaddr-v2-03.txt		draft-ietf-fax-faxaddr-v2-04.txt >
	Network Working C. Allocchio		A new Request for Comments is now available in online RFC libraries.
	Group GARR-Italy
	INTERNET-DRAFT March 2001
	Obsoletes: RFC2304 Expires: September 2001
	Updates: RFC2846 File: draft-ietf-fax-faxaddr-v2-03.txt
	Minimal FAX address format in Internet Mail
	Status of this Memo
	This document is an Internet Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering
	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
	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
	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.
	Copyright Notice
	Copyright (C) The Internet Society (1999). All Rights Reserved.
	Important Note for the RFC Editor:
	Within this document all references and occurences given as
	"RFC2303bis" need to be replaced by "RFCxxxx", where "xxxx" is
	the number which will be assigned to draft-ietf-fax-minaddr-v2-03.txt
	and all references and occurences given as "RFC2304bis" need to
	be replaced by "RFCyyyy", where "yyyy" is the number which will be
	assigned to THIS documnt.
	Also References given in [1] and [2] should eventually be updated with
	the numbers assigned to the documents obsoleting RFC821 and RFC822.
	Abstract
	This memo describes a simple method of encoding GSTN addresses of
	facsimile devices in the local-part of Internet email addresses.
	As with all Internet mail addresses, the left-hand-side (local- part)
	of an address generated according to this specification, is not to be
	interpreted except by the MTA that is named on the right-hand-side
	(domain).
	1. Introduction
	Since the very first e-mail to fax gateway objects appeared, a
	number of different methods to specify a fax address as an e-mail
	address have been used by implementors. Several objectives for this
	methods have been identified, like to enable an e-mail user to send
	and receive faxes from his/her e-mail interface, to allow some kind of
	"fax over e-mail service" transport (possibly reducing the costs of
	GSTN long distance transmissions) while using the existing e-mail
	infrastructure.
	This memo describes the MINIMAL addressing method and standard
	extensions to encode FAX addresses into e-mail addresses, as required
	in reference [13]. The opposite problem, i.e. to allow a traditional
	numeric-only fax device user to access the e-mail transport service,
	is not discussed here.
	This IANA forms used to register the standard elements defined here
	are given in the "IANA Considerations" chapter (section 7 of this
	document).
	All implementations supporting FAX over e-mail address format MUST
	support this minimal specification.
	1.1 Terminology and Syntax conventions
	In this document the formal definitions are described using ABNF
	syntax, as defined into [7]. We will also use some of the "CORE
	DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The
	exact meaning of the capitalised words
	"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
	"SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"
	is defined in reference [6].
	In this document the following new terms are also defined:
	I-fax device:
	an I-pstn device type [13] which is able to communicate either
	directly or indirectly with the traditional FAX over GSTN
	service;
	mta-I-fax:
	the Internet domain name which identifies uniquely an I-fax
	device over the Internet (see also mta-I-pstn in [13]);
	fax-email:
	the complete Internet e-mail address structure which is used to
	transport a FAX address over the Internet e-mail service (see
	also pstn-email in [13]).
	2. Minimal Fax address
	The minimal fax address within e-mail has been defined for consistency
	with reference [13] and it contains two elements: the fax-mbox and
	an optional qualif-type1 element.
	More precisely the GSTN minimal address specification requires the
	use of a unique service-selector for each specific application
	(section 2 in [13]).
	The "service-selector" defined for the fax service is as follows:
	service-selector = "FAX"
	In the syntax for the fax address a qualif-type1 element has been
	defined for support of T.30/T.33 subaddresses (see section 2 of [13]).
	The use of this element is OPTIONAL, but compliant implementations
	MUST be able to support and correctly interpret it when present.
	Its definition is as follows:
	qualif-type1 = "/" t33-sep "=" sub-addr
	where
	t33-sep = "T33S"
	sub-addr = 1*( DIGIT )
	Thus, the minimal specification of a fax in e-mail address is:
	fax-address = fax-mbox [ "/T33S=" sub-addr ]
	fax-mbox = "FAX=" global-phone
	Notes:
	For the case of a single subaddress, only numbers are allowed in
	<sub-addr> which is consistent with T.30, T.33, and this document.
	While T.30 and T.33 use SPACE to pad its field, padding isn't necessary
	in the <sub-addr> field defined by this document.
	For the case of multiple subaddresses, T.33 specifies the "#"
	character be used to specify multiple subaddreses. However,
	only digits are permitted in the <sub-addr> field defined by this
	document. Refer to section 4.1 in case multiple <sub-addr> per
	per <fax-mbox> need to be specified.
	The Minimal supported syntax for global-phone (as described in
	section 2.1 of reference [13]) is:
	global-phone = "+" 1*( DIGIT / written-sep )
	written-sep = ( "-" / "." )
	Refer to section 2.1 in [13] for other important considerations about
	the global-phone element.
	2.2 Some examples of a minimal "fax-address"
	Some examples of minimal fax-address follows:
	FAX=+3940226338
	FAX=+12027653000/T33S=1387
	FAX=+33-1-88335215
	Note:
	the examples shown are just for illustration purpouses.
	3. The e-mail address of the I-fax device: mta-I-fax
	An "I-fax device" has, among its characteristics, a unique
	Internet domain name which identifies it on the Internet. Within
	Internet mail, this is the Right Hand Side (RHS) part of the
	address, i.e. the part on the right of the "@" sign. For purpouses
	of this document we will call this "mta-I-fax"
	mta-I-fax = domain
	For "domain" strings used in SMTP transmissions, the string MUST
	conform to the requirements of that standard's <domain>
	specifications [1], [3]. For "domain" strings used in message
	content headers, the string MUST conform to the requirements of the
	relevant standards [2], [3].
	Note: the use of "domain names" or "domain literals"
	is permitted in addresses in both the SMTP envelope
	and message header fields.
	4. The fax-email
	The complete structure used to transfer a minimal FAX address over
	the Internet e-mail transport system is called "fax-email". This
	object is a an e-mail address which conforms to [2] and [3]
	"addr-spec" syntax, with structure refinements which allows the
	FAX number to be identified.
	fax-email = ["""] ["/"] fax-address ["/"] ["""] "@" mta-I-fax
	Implementors' note:
	The optional "/" characters can result from translations from
	other transport gateways (such as some X.400 gateways) which
	have included the "/" as an optional element. Implementations
	MUST accept the optional slashes but SHOULD NOT generate them.
	Gateways are allowed to strip them off when converting to
	Internet mail addressing. The relevant standard [2], [3] define
	exactly when the optional "quotes" characters surrounding the
	entire local part (i.e. the part on the left of the "@" character
	into the fax-email) MUST be added.
	4.1 Multiple subaddresses
	There are some instances in GSTN applications where multiple
	subaddresses are used: T.33 subaddresses in fax service are one of
	these cases. In e-mail practice a separate and unique e-mail
	address is always used for each recipient; as such, if multiple T.33
	subaddresses are present, the use of multiple "fax-email" elements
	is REQUIRED.
	Implementors' note:
	The UA MAY accept multiple subaddress elements for the same
	global-phone, but it MUST generate multiple "fax-mbox" elements
	when submitting the message to the MTA.
	4.2 Some examples of minimal "fax-email"
	Some examples of minimal fax-email addresses follows:
	FAX=+3940226338@faxworld.org
	FAX=+12027653000/T33S=1387@faxworld.org
	/FAX=+33-1-88335215/@faxworld.org
	Note:
	the examples shown are just for illustration purpouses.
	5. Conclusion
	This proposal creates a minimal standard encoding for FAX addresses
	within the global e-mail transport system. The proposal is consistent
	with existing e-mail standards.
	6. Security Considerations
	This document specifies a means by which FAX addresses can be
	encoded into e-mail addresses. Since e-mail routing is determined by
	Domain Name System (DNS) data, a successful attack to DNS could
	disseminate tampered information, which causes e-mail messages to be
	diverted via some MTA or Gateway where the security of the software
	has been comprimised.
	There are several means by which an attacker might be able to deliver
	incorrect mail routing information to a client. These include: (a)
	compromise of a DNS server, (b) generating a counterfeit response to
	a client's DNS query, (c) returning incorrect "additional
	information" in response to an unrelated query. Clients SHOULD ensure
	that mail routing is based only on authoritative answers. Once DNS
	Security mechanisms [5] become more widely deployed, clients SHOULD
	employ those mechanisms to verify the authenticity and integrity of
	mail routing records.
	7. IANA Considerations
	The IANA registration forms for "FAX" service-selector and "T33S"
	qualif-type1 elements are defined here. These forms update the
	previous registration forms defined in [15].
	7.1 IANA Registration form for updated value of GSTN
	address service-selector "FAX"
	To: IANA@isi.edu
	Subject: Registration of updated 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 RFC2304bis and RFC2303bis
	Security Considerations:
	See the Security Consideration section of RFC2304bis.
	Person & email address to contact for further information:
	Claudio Allocchio
	INFN-GARR
	c/o Sincrotrone Trieste
	SS 14 Km 163.5 Basovizza
	I 34012 Trieste
	Italy
	RFC822: Claudio.Allocchio@garr.it
	X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
	Phone: +39 040 3758523
	Fax: +39 040 3758565
	7.2 IANA Registration form for updated value of GSTN
	address qualit-type1 keyword "T33S" and value
	To: IANA@isi.edu
	Subject: Registration of updated 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 RFC2304bis.
	Person & email address to contact for further information:
	Claudio Allocchio
	INFN-GARR
	c/o Sincrotrone Trieste
	SS 14 Km 163.5 Basovizza
	I 34012 Trieste
	Italy
	RFC822: Claudio.Allocchio@garr.it
	X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
	Phone: +39 040 3758523
	Fax: +39 040 3758565
	8. Author's Address
	Claudio Allocchio
	INFN-GARR
	c/o Sincrotrone Trieste
	SS 14 Km 163.5 Basovizza
	I 34012 Trieste
	Italy
	RFC822: Claudio.Allocchio@garr.it
	X.400: C=it;A=garr;P=garr;S=Allocchio;G=Claudio;
	Phone: +39 040 3758523
	Fax: +39 040 3758565
	9. References
	[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
	August 1982. --> DRUMS?
	[2] Crocker, D., " Standard for the format of ARPA Internet text
	messages", STD 11, RFC 822, August 1982. --> DRUMS?
	[3] Braden, R., "Requirements for Internet hosts - application and
	support", RFC 1123, October 1989.
	[4] Malamud, C. and M. Rose, "Principles of Operation for the
	TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
	1528, October 1993.
	[5] Eastlake, D. and C. Kaufman, "Domain Name System Security
	Extensions", RFC 2065, January 1997.
	[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, March 1997.
	[7] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications", RFC 2234, November 1997.
	[8] ITU F.401 - Message Handling Services: Naming and Addressing for		RFC 3192
	Public Message Handling Service; recommendation F.401 (August
	1992)
	[9] ITU F.423 - Message Handling Services: Intercommunication		Title: Minimal FAX address format in Internet Mail
	Between the Interpersonal Messaging Service and the Telefax		Author(s): C. Allocchio
	Service; recommendation F.423 (August 1992)		Status: Standards Track
			Date: October 2001
			Mailbox: Claudio.Allocchio@garr.it
			Pages: 11
			Characters: 18880
			Obsoletes: 2304
			Updates: 2846
	[10] ITU E.164 - The International Public Telecommunication Numbering		I-D Tag: draft-ietf-fax-faxaddr-v2-04.txt
	Plan E.164/I.331 (May 1997)
	[11] ITU T.33 - Facsimile routing utilizing the subaddress;		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3192.txt
	recommendation T.33 (July, 1996)
	[12] ETSI I-ETS 300,380 - Universal Personal Telecommunication		This memo describes a simple method of encoding Global Switched
	(UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender		Telephone Network (GSTN) addresses of facsimile devices in the
	for acoustical coupling to the microphone of a handset telephone		local-part of Internet email addresses.
	(March 1995)
	[13] Allocchio, C., "Minimal GSTN address format in Internet Mail",		This document is a product of the Internet Fax Working Group of the
	RFC 2303bis, xxxx 2001.		IETF.
	[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping		This is now a Draft Standard Protocol.
	between X.400 and RFC 822/MIME", RFC 2156, January 1998.
	[15] Allocchio, C. "GSTN address element extensions in e-mail		This document specifies an Internet standards track protocol for
	services", RFC 2846, June 2000.		the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	10. Full Copyright Statement		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) The Internet Society (1999). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	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		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	428 lines changed or deleted		36 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/