idnits 2.17.1 draft-ietf-fax-faxservice-enum-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 228 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2004) is 7252 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3761 (ref. 'ENUMbis') (Obsoleted by RFC 6116, RFC 6117) ** Obsolete normative reference: RFC 2305 (Obsoleted by RFC 3965) -- Possible downref: Non-RFC (?) normative reference: ref. 'FFPIM' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Toyoda, PCC 2 Internet Draft D. Crocker, Brandenburg 3 draft-ietf-fax-faxservice-enum-03 4 Expires: December 2004 June 2004 6 IFAX service of ENUM 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full 11 conformance with all provisions of Section 10 of 12 RFC2026. Internet-Drafts are working documents of the 13 Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum 18 of six months and may be updated, replaced, or 19 obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be 28 accessed at 29 http://www.ietf.org/shadow.html. 31 COPYRIGHT NOTICE 33 Copyright (C) The Internet Society (2001). All Rights 34 Reserved. 36 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD 37 NOT", and "MAY" in this document are to be interpreted 38 as defined in "Key words for use in RFCs to Indicate 39 Requirement Levels" [KEYWORDS]. 41 Abstract 43 This document describes the functional specification 44 and the definition of the ENUM NAPTR record, for IFax 45 service. IFax is "Facsimile using Internet Mail". For 46 this use, the DNS returns the email address of the 47 referenced IFax system. This mechanism allows email-based 48 fax communication to use telephone numbers, rather than 49 requiring that the sender already know the recipient 50 email address. 52 1. Functional Specification 54 An IFax client makes an [ENUMbis] DNS query, using the target 55 system's telephone number. The returned NAPTR record 56 specifies an email address that is to be used for reaching 57 the target system. The email address is then used in 58 accordance with "Simple Mode of Facsimile using Internet 59 Mail" [RFC2305] or "Extended Facsimile using Internet 60 Mail" [RFC2532]. "Full Mode Fax Profile for Internet Mail" [FFPIM] 61 is applied when it is approved as an Internet standards-track 62 specification. 64 2. IFax service Registration 66 Service Name : "E2U+ifax" 68 Type: "ifax" 70 Subtype: "mailto" 72 URI Scheme: "mailto" 73 The URI Scheme is "mailto" because facsimile is a profile of 74 standard Internet mail and uses standard Internet mail addressing. 76 Functional Specification: see section 1 78 Security Considerations: see section 3 80 Intended usage: COMMON 82 Author: Kiyoshi Toyoda(toyoda.kiyoshi@jp.panasonic.com) 83 Dave Crocker(dcrocker@brandenburg.com) 85 3. Security Consideration 87 DNS, as used by ENUM, is a global, distributed database. Thus any 88 information stored there is visible to anyone anonymously. Whilst 89 this is not qualitatively different from publication in a Telephone 90 Directory, it does open the data subject to having "their" 91 information collected automatically without any indication that 92 this has been done or by whom. 94 Such data harvesting by third parties is often used to generate 95 lists of targets for unrequested information; in short, they are 96 used to address "spam". Publication of a telephone number in ENUM, 97 especially when it is an associated Internet Fax service, may be 98 used to send "junk faxes" for example. 100 In the case of electronic mail, users subscribed to mailing lists 101 can have "sacrificial" email accounts. These special-purpose 102 addresses help the user to filter out unrequested email that is 103 sent to them. This is not so easy with published telephone 104 numbers. The PSTN E.164 number assignment process is much more 105 involved and less flexible; usually a single E.164 number (or a 106 fixed range of numbers) is associated with each PSTN access. Thus 107 it is not possible to use a "sacrificial" phone number. 109 Due to the implications of publishing data on a globally accessible 110 database, as a principle the data subject MUST give their explicit 111 informed consent to data being published in ENUM. 113 Internet Fax is based on use of existing Internet mail. Developers 114 and users should also consider the Security Consideration section 115 in [RFC2305] and [RFC2532]. 117 In addition to the specific security considerations given above, 118 the Security Consideration section of [ENUMbis] applies to this 119 document. 121 4. Example 122 The following is an example of the use of IFax service 124 in a NAPTR record. 126 $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa 127 IN NAPTR 10 10 "u" "E2U+ifax:mailto" 128 "!^.*$!mailto:toyo@example.com!" 130 5. IANA CONSIDERATIONS 132 This specification creates a DNS NAPTR registration, according to 133 the terms specified in [ENUMbis] 135 The registration details are contained in section 2, 136 "Fax service Registration", above. 138 6. REFERENCES 139 6.1 NORMATIVE REFERENCES 140 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 141 Requirement Levels", RFC2119, March 1997 143 [ENUMbis] Falstrom, P., M. Mealling, "The E.164 to Uniform 144 Resource Identifiers (URI) Dynamic Delegation Discovery 145 System (DDDS) Application (ENUM)", RFC3761, April 2004 147 [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A 148 Simple Mode of Facsimile Using Internet Mail", RFC 2305, 149 March 1998. 151 [RFC2532] Masinter, L., D. Wing, "Extended Facsimile Using 152 Internet Mail", March 1999 154 [FFPIM] Crocker, D., G. Klyne, "Full-mode Fax Profile for 155 Internet Mail", DRAFT-IETF-FAX-FFPIM-04(work in progress), 156 June 2004 158 7. AUTHORS' ADDRESSES 160 Kiyoshi Toyoda 161 Network Technology Development Center 162 Panasonic Communications Co., Ltd. 163 2-3-8 Shimomeguro, Meguro-ku, Tokyo 153-8687, Japan 165 tel: +81-3-5745-3921 166 fax: +81-3-5434-7156 167 toyoda.kiyoshi@jp.panasonic.com 169 Dave Crocker 170 Brandenburg InternetWorking 171 675 Spruce Drive 172 Sunnyvale, CA 94086 USA 174 Tel: +1.408.246.8253 175 dcrocker@brandenburg.com 177 8. FULL COPYRIGHT STATEMENT 179 Copyright (C) The Internet Society (2001). All Rights 180 Reserved. 182 This document and translations of it may be copied and 183 furnished to others, and derivative works that comment 184 on or otherwise explain it or assist in its 185 implementation may be prepared, copied, published and 186 distributed, in whole or in part, without restriction 187 of any kind, provided that the above copyright notice 188 and this paragraph are included on all such copies and 189 derivative works. However, this document itself may 190 not be modified in any way, such as by removing the 191 copyright notice or references to the Internet Society 192 or other Internet organizations, except as needed for 193 the purpose of developing Internet standards in which 194 case the procedures for copyrights defined in the 195 Internet Standards process must be followed, or as 196 required to translate it into languages other than 197 English. 199 The limited permissions granted above are perpetual and 200 will not be revoked by the Internet Society or its 201 successors or assigns. 203 This document and the information contained herein is 204 provided on an "AS IS" basis and THE INTERNET SOCIETY 205 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 206 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 207 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 208 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 209 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 210 PARTICULAR PURPOSE.