1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2304.txt b/doc/rfc/rfc2304.txt
new file mode 100644
index 0000000..d0d2f0b
--- /dev/null
+++ b/doc/rfc/rfc2304.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      C. Allocchio
+Request for Comments: 2304                                   GARR-Italy
+Category: Standards Track                                    March 1998
+
+
+
+
+              Minimal FAX address format in Internet Mail
+
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for 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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+IESG NOTE
+
+   This memo describes a simple method of encoding PSTN 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. Two major objectives for this were
+
+     - enable an e-mail user to send faxes from his/her e-mail
+       interface;
+
+     - enable some kind of "fax over e-mail service" transport, to
+       reduce the costs of fax transmissions, and use the existing
+       e-mail infrastructure.
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 1]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+   This memo describes the MINIMAL addressing method and standard
+   extensions to encode FAX addresses in 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.
+
+   All implementations supporting this FAX over e-mail address format
+   MUST support as a minimum the specification described in this
+   document.  The generic complex case of converting the whole PSTN
+   addressing in e-mail is out of scope in this minimal specification:
+   there is some work in progress in the field, where also a number of
+   standard optional extensions are being defined.
+
+   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].
+
+2. Minimal Fax address
+
+   The "service-selector" defined in section 2 of reference [13] for the
+   fax service is:
+
+      service-selector = "FAX"
+
+   The minimal addressing for the fax service also requires support for
+   a "qualif-type1" element (see section 2 of reference [13]).  This
+   element is an OPTIONAL element of the fax address, but its support,
+   when present, is REQUIRED:
+
+      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
+
+
+
+Allocchio                   Standards Track                     [Page 2]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+   Note:
+     See section 4.1 in case multiple sub-addr per fax-mbox need to be
+     specified.
+
+   The Minimal supported syntax for global-phone (as described in
+   section reference [13]) is:
+
+
+   global-phone = "+" 1*( DIGIT , written-sep )
+
+   written-sep = ( "-" / "." )
+
+   The use of other dialling schemas for PSTN numbers (like private
+   numbering plans or local dialling conventions) is also allowed.
+   However, this does not preclude nor remove the minimal compulsory
+   requirement to support the "global-phone" syntax as defined above.
+
+   Any non "global-phone" dialling schema MUST NOT use the leading "+"
+   between the "=" sign and the dialling string. The "+" sign is
+   strictly reserved for the standard "global-phone" syntax.
+
+   Note:
+     The specification of these different dialling schemas is out of
+     scope for this minimal specification.
+
+   User specification of PSTN e-mail addresses will be facilitated if
+   they can insert these separators between dial elements like digits
+   etc.  For this reason we allow them in the syntax the written-sep
+   element.
+
+   Implementors' note:
+     Use of the written-sep elements is allowed, but not recommended.
+     Any occurences of written-sep elements in a pstn-mbox MUST be
+     ignored by all conformant implementations. User Agents SHOULD
+     remove written-sep elements before submitting messages to the
+     Message Transport System.
+
+2.2 Some examples of a minimal "fax-address"
+
+      FAX=+3940226338
+
+      FAX=+12027653000/T33S=1387
+
+      FAX=+33-1-88335215
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 3]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+3. The e-mail address of the I-fax device: mta-I-fax
+
+   An "I-fax device" has an e-mail address, or to be more exact, a name
+   which enables a mail system to identify it on the e-mail global
+   system.
+
+   In Internet mail, this is the Right Hand Side (RHS) part of the
+   address, i.e. the part on the right of the "@" sign. 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: in both cases, the standards permit use of "domain names" or
+         "domain literals" in addresses.
+
+
+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 an e-mail address which conforms to RFC822 [2] and RFC1123
+   [3] "addr-spec" syntax, with some extra structure which allows the
+   FAX number to be identified.
+
+         fax-email =  ["/"] fax-address ["/"] "@" mta-I-fax
+
+   Implementors' note:
+     The optional "/" characters can result from other mail transport
+     services gateways, where it is also 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.
+
+     It is essential to remind that "fax-address" element MUST strictly
+     follow the "quoting rules" spcified in the relevant standards [2],
+     [3]
+
+4.1 Multiple subaddresses
+
+   In case a particular service requires multiple T.33 subaddresses, and
+   these subaddresses need to be given on the same "fax-mbox", multiple
+   "fax-email" elements will be used.
+
+
+
+Allocchio                   Standards Track                     [Page 4]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+   Implementors' note:
+     The UA could accept multiple subaddress elements for the same
+     global-phone, but it must generate multiple "fax-mbox" elements
+     when passing the message to the MTA.
+
+4.2 Some examples of minimal "fax-email"
+
+      FAX=+3940226338@faxworld.org
+
+      FAX=+12027653000/T33S=1387@faxworld.org
+
+      /FAX=+33-1-88335215/@faxworld.org
+
+5. Conclusion
+
+   This proposal creates a minimal standard encoding for FAX addresses
+   within the global e-mail transport system. The proposal requires no
+   changes to existing e-mail software.
+
+6. Security Considerations
+
+   This document specifies a means by which FAX addresses can be encoded
+   into e-mail addresses. As routing of e-mail messages is determined by
+   Domain Name System (DNS) information, a successful attack on this
+   service could force the mail path via some particular gateway or
+   message transfer agent where mail security can be affected by
+   compromised software.
+
+   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. Author's Address
+
+   Claudio Allocchio
+   Sincrotrone Trieste
+   SS 14 Km 163.5 Basovizza
+   I 34012 Trieste
+   Italy
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 5]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+   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
+
+8. References
+
+   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+        August 1982.
+
+   [2]  Crocker, D., " Standard for the format of ARPA Internet text
+        messages", STD 11, RFC 822, August 1982.
+
+   [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
+        Public Message Handling Service; recommendation F.401 (August
+        1992)
+
+   [9]  ITU F.423 - Message Handling Services: Intercommunication
+        Between the Interpersonal Messaging Service and the Telefax
+        Service; recommendation F.423 (August 1992)
+
+   [10] ITU E.164 - Numbering plan for the ISDN era; recommendation
+        E.164/I.331 (August 1991)
+
+   [11] ITU T.33 - Facsimile routing utilizing the subaddress;
+        recommendation T.33 (July, 1996)
+
+   [12] ETSI I-ETS 300,380 - Universal Personal Telecommunication
+        (UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender
+        for acoustical coupling to the microphone of a handset telephone
+        (March 1995)
+
+
+
+Allocchio                   Standards Track                     [Page 6]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+   [13] Allocchio, C., " Minimal FAX address format in Internet Mail",
+        RFC 2303, March 1998.
+
+   [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+        between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 7]
+
+RFC 2304               Minimal FAX address format             March 1998
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 8]
+