idnits 2.17.1 draft-josefsson-mime-dns-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (March 5, 2004) is 7358 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) == Unused Reference: '1' is defined on line 196, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2048 (ref. '3') (Obsoleted by RFC 4288, RFC 4289) ** Downref: Normative reference to an Experimental RFC: RFC 2540 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 2440 (ref. '5') (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '6') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2538 (ref. '7') (Obsoleted by RFC 4398) -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. '8') (Obsoleted by RFC 3852) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft March 5, 2004 4 Expires: September 3, 2004 6 Domain Name System Media Types 7 draft-josefsson-mime-dns-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 3, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document register the media types application/dns and text/dns, 38 in accordance with RFC 2048 [3]. The application/dns media type is 39 used to identify data on the detached Domain Name System (DNS) format 40 described in RFC 2540 [4]. The text/dns media type is used to 41 identify master files as described in RFC 1035 [2]. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. MIME type registration of application/dns . . . . . . . . . . . 4 47 3. MIME type registration of text/dns . . . . . . . . . . . . . . . 5 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 49 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 50 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 51 Normative References . . . . . . . . . . . . . . . . . . . . . . 7 52 Informative References . . . . . . . . . . . . . . . . . . . . . 7 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 54 Intellectual Property and Copyright Statements . . . . . . . . . 9 56 1. Introduction 58 Domain Name System (DNS) information is traditionally stored in text 59 files, so called master files or zone files. The format is described 60 in section 5 of RFC 1035 [2]. 62 DNS data can also be stored in a "detached" format, intended for 63 archiving purposes, described in RFC 2540 [4]. 65 This document register MIME media types for the two data formats, 66 following the registration procedures described in RFC 2048 [3]. 68 2. MIME type registration of application/dns 70 To: ietf-types@iana.org 71 Subject: Registration of MIME media type application/dns 73 MIME media type name: application 75 MIME subtype name: dns 77 Required parameters: None. 79 Optional parameters: None. 81 Encoding considerations: The data format is binary, and data must be 82 transfered unmodified. Using encodings intended for textual parts is 83 not recommended. 85 Security considerations: This media type identify content as being 86 detached DNS information, as documented in RFC 2540 [4]. This data 87 may be security relevant according to RFC 2538 [7], or secured 88 information according to RFC 2535 [6]. Securing the content further 89 may be done by standard techniques, such as OpenPGP [5] or CMS [8], 90 but this is outside of the scope here. Further security assessments 91 are not available at this point. 93 Interoperability considerations: The encoding of detached DNS 94 information is, unlike textual master files, well defined. No further 95 interoperability considerations are known. 97 Published specification: The format of data that could be tagged with 98 this media type is documented in RFC 2540 [4]. 100 Applications which use this media type: DNS related software, 101 including software storing and using certificates stored in DNS. 103 Additional information: 104 Magic number(s): None. 105 File extension(s): Unknown. 106 Macintosh File Type Code(s): Unknown. 108 Person & email address to contact for further information: 110 Simon Josefsson simon@josefsson.org 112 Intended usage: LIMITED USE 114 Author/Change controller: simon@josefsson.org 116 3. MIME type registration of text/dns 118 To: ietf-types@iana.org 119 Subject: Registration of MIME media type text/dns 121 MIME media type name: text 123 MIME subtype name: dns 125 Required parameters: None. 127 Optional parameters: None. 129 Encoding considerations: The data is textual, and should be 130 transfered in a line oriented mode. Text literals may contain CRLF 131 within the text. Binary transports is possible between systems that 132 use the same end-of-line conventions. Master files are in general 133 ASCII, but non-ASCII octet values may occur and are treated as opaque 134 values by DNS software (compare RFC 1035 section 5). The master file 135 format permits encoding arbitrary octet values using the "\DDD" 136 encoding. The use of "\DDD" encoding can be more reliable than 137 transporting non-ASCII through MIME transports, if data passes 138 through a gateway that re-encode the character data. 140 Security considerations: This media type identify content as being 141 DNS information in "master file" format, as documented in RFC 1035 142 [2]. The DNS data may be security relevant according to RFC 2538 [7], 143 or secured information according to RFC 2535 [6]. Securing the 144 content further may be done by standard techniques, such as OpenPGP 145 [5] or CMS [8], but this is outside of the scope here. Further 146 security assessments are not available at this point. 148 Interoperability considerations: There are interoperability concerns 149 with master files, due to the wide spread use of vendor specific 150 extensions. Non-ASCII comments within master files may have been 151 encoded in a locally chosen character sets, which may be difficult to 152 transport interoperably. Non-ASCII data in general can become 153 corrupted by re-encoding gateways. To achieve interoperability, you 154 can use the master file format described in the specification and the 155 "\DDD" encoding for non-ASCII octets. 157 Published specification: The format of data that could be tagged with 158 this MIME type is documented in RFC 1035 [2]. 160 Applications which use this media type: DNS related software, 161 including software storing and using certificates stored in DNS. 163 Additional information: 164 Magic number(s): None. 165 File extension(s): 'soa' and 'zone' are known to be used. 166 Macintosh File Type Code(s): Unknown. 168 Person & email address to contact for further information: 170 Simon Josefsson simon@josefsson.org 172 Intended usage: LIMITED USE 174 Author/Change controller: simon@josefsson.org 176 4. Security Considerations 178 Security considerations are discussed in the security considerations 179 clause of the MIME registrations in section 2 and 3. 181 5. IANA Considerations 183 The IANA is asked to register the MIME media types application/dns 184 and text/dns using the registration templates in section 2 and 3, 185 according to the procedure described in RFC 2048 [3]. 187 6. Acknowledgments 189 Thanks to D. Eastlake for suggesting text/dns. Thanks to Keith Moore 190 for reviewing earlier versions of this document. The author 191 acknowledges the RSA Laboratories for supporting the work that led to 192 this document. 194 Normative References 196 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 197 13, RFC 1034, November 1987. 199 [2] Mockapetris, P., "Domain names - implementation and 200 specification", STD 13, RFC 1035, November 1987. 202 [3] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 203 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 204 13, RFC 2048, November 1996. 206 [4] Eastlake, D., "Detached Domain Name System (DNS) Information", 207 RFC 2540, March 1999. 209 Informative References 211 [5] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 212 Message Format", RFC 2440, November 1998. 214 [6] Eastlake, D., "Domain Name System Security Extensions", RFC 215 2535, March 1999. 217 [7] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the 218 Domain Name System (DNS)", RFC 2538, March 1999. 220 [8] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, 221 August 2002. 223 Author's Address 225 Simon Josefsson 227 EMail: simon@josefsson.org 229 Intellectual Property Statement 231 The IETF takes no position regarding the validity or scope of any 232 intellectual property or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; neither does it represent that it 236 has made any effort to identify any such rights. Information on the 237 IETF's procedures with respect to rights in standards-track and 238 standards-related documentation can be found in BCP-11. Copies of 239 claims of rights made available for publication and any assurances of 240 licenses to be made available, or the result of an attempt made to 241 obtain a general license or permission for the use of such 242 proprietary rights by implementors or users of this specification can 243 be obtained from the IETF Secretariat. 245 The IETF invites any interested party to bring to its attention any 246 copyrights, patents or patent applications, or other proprietary 247 rights which may cover technology that may be required to practice 248 this standard. Please address the information to the IETF Executive 249 Director. 251 Full Copyright Statement 253 Copyright (C) The Internet Society (2004). All Rights Reserved. 255 This document and translations of it may be copied and furnished to 256 others, and derivative works that comment on or otherwise explain it 257 or assist in its implementation may be prepared, copied, published 258 and distributed, in whole or in part, without restriction of any 259 kind, provided that the above copyright notice and this paragraph are 260 included on all such copies and derivative works. However, this 261 document itself may not be modified in any way, such as by removing 262 the copyright notice or references to the Internet Society or other 263 Internet organizations, except as needed for the purpose of 264 developing Internet standards in which case the procedures for 265 copyrights defined in the Internet Standards process must be 266 followed, or as required to translate it into languages other than 267 English. 269 The limited permissions granted above are perpetual and will not be 270 revoked by the Internet Society or its successors or assignees. 272 This document and the information contained herein is provided on an 273 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 274 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 275 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 276 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 277 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 279 Acknowledgment 281 Funding for the RFC Editor function is currently provided by the 282 Internet Society.