idnits 2.17.00 (12 Aug 2021) /tmp/idnits56439/draft-nottingham-dns-media-tree-00.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (January 2003) is 7059 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) ** Downref: Normative reference to an Informational RFC: RFC 1591 ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Nottingham 2 Internet-Draft January 2003 3 Expires: July 2, 2003 5 The 'dns' Media Type Registration Tree 6 draft-nottingham-dns-media-tree-00 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on July 2, 2003. 30 Copyright Notice 32 Copyright (C) The Internet Society (2003). All Rights Reserved. 34 Abstract 36 This document specifies the 'dns' media subtype registration tree, 37 which is intended to ease the deployment of new Internet applications 38 and their associated media types without the need for coordination 39 with a central registry. 41 1. Requirements notation 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in [RFC2119]. 47 2. Introduction 48 The registration proceedures for Internet media types [RFC2048] allow 49 for the specification of media type trees, which allow for faceted 50 names to be described in order to increase the efficiency and 51 flexibility of the registration process. They also allows for the 52 creation of new registration trees, with the advice and consent of 53 the IESG. 55 This specification describes one such tree. 57 3. Motivation 59 The Internet media type system was designed to encourage certain 60 properties, and arguably has been quite successful because of its 61 approach. In particular, IANA acts as a central registry to bring 62 coordination and convenience, and various levels of community review 63 are required before a media type may be registered, to assure some 64 level of quality in and appropriate application of media types. 66 However, the arrival of the Web, and in particular XML, has changed 67 the conditions under which formats are created and used. XML allows 68 the creation of business-specific document and protocol formats by 69 end users. Often, these parties are unfamiliar with IETF and IANA 70 process for registration of media types, and do not have a 71 requirement for recognition by a centralized registry. As such, the 72 cost of media type registration is not justified in the view of some 73 parties that are minting new formats. 75 As a result, many formats are created without corresponding media 76 types (often under the umbrella of 'text/xml' or 'application/xml'). 77 Such formats are not first-class citizens on the Internet or the Web; 78 one cannot content negotiate for them, for example, and one cannot 79 use existing software dispatch mechanisms in MIME software to 80 accommodate them. 82 It should be noted that these undesirable effects disproportionately 83 affect those who wish to use a format in ways that may not have been 84 forseen by its creators. As such, the registration system indirectly 85 discourages the wide use of those mechanisms that leverage media 86 types. 88 Current registration proceedures do allow for some flexibility to 89 accommodate vendor-specific formats (the .vnd tree), "vanity" formats 90 (the .prs tree) and ad hoc, experimental formats (the x. tree and its 91 predecessor, the 'x-' convention). Unfortunately, these mechanisms do 92 not address the problems described here; the x- convention is too 93 brittle for most uses (and indeed its use has been discouraged for 94 some time), and the .vnd and .prs trees are still based on a 95 centralized registry. 97 This specification proposes that the widely recognized DNS 98 infrastructure be leveraged to act as a distributed registry, to 99 avoid the possibility of collision, whilst removing the need for an 100 additional centralized registry. The approach is similar to URI 101 schemes that also leverage the DNS to provide locally-managed name 102 spaces. 104 4. The 'dns' Tree 106 The 'dns' media subtype tree is intended to be used to identify 107 proprietary, ad hoc, experimental, or limited deployment formats. 109 It follows the conventions of faceted name trees as specified by 110 [RFC2048], and is distinguished by the leading facet 'dns.'. This 111 facet MUST be followed by one or more dot-delimited facets that are 112 derived from a domain name, in reverse order. Finally, those facets 113 MUST be followed by on or more facets that indicate the format's 114 identity within that name space. 116 Media types using this tree MUST be minted with the knowledge and 117 permission of the authority responsible for the corresponding 118 Internet domain name. The domain name used MUST be registered in the 119 Internet Registry, as delegated by IANA (see [RFC1591]). 121 For example, if the entity responsible for example.com wished to 122 register a textual media type with the name 'foo' in this fashion, 123 its media type might be: 125 text/dns.com.example.foo 127 XML-based formats SHOULD be conformant with [RFC3023], e.g.: 129 application/dns.com.example.foo+xml 131 If example.com were a multinational concern, it may wish to delegate 132 authority for minting new types to regional departments. It could do 133 so by mandating an additional facet; an application media type minted 134 by the Australian division might be: 136 application/dns.com.example.au.bar 138 whilst a completely separate application format, also identified as 139 'bar' and minted by the U.S. division might be distinguished as: 141 application/dns.com.example.us.bar 143 4.1 The 'doc' Attribute 144 Media types in the dns tree MAY use the 'doc' attribute, which 145 indicates a URL [RFC2396] that can be used to locate documentation of 146 the identified format. 148 For example: 150 application/dns.com.example.foo; doc="http://www.example.com/formats/ 151 foo.html" 153 The 'doc' attribute is only informative, and MUST NOT be interpreted 154 to alter the nature of the format identified; i.e., a media type with 155 a 'doc' attribute of "foo" MUST be considered equivalent to the same 156 media type with a 'doc' attribute of "bar", or one without a 'doc' 157 attribute. 159 4.2 Format-Specific Attributes 161 Formats using this dns tree MAY designate their own attributes, which 162 SHOULD be documented at or referenced from the URL specified in the 163 'doc' attribute, if present. 165 5. IANA Considerations 167 Implementation of the dns tree does not require IANA coordination. 168 Any media type conformant with this specification is considered to be 169 registered with IANA. 171 6. Security Considerations 173 6.1 Change of Ownership 175 Over time, domain names may change ownership. Without proper care, 176 media types created by a domain name's previous owner might collide 177 with those created by the new owner. 179 As a result, when domains which have been used in the registration of 180 media types in the dns tree change hands, the previous owner SHOULD 181 take care to communicate existing media types to the new owner, and 182 the new owner SHOULD take care to avoid collisions. Previous owners 183 MAY publish a transition plan to a new domain, if doing so is judged 184 to cause minimal disruption. 186 6.2 Unauthorized Registration 188 Media types using the dns tree have no enforced relationship to the 189 domain names that they are based upon; the use of domain names is 190 only a convention to assure proper name spacing. Implementations 191 SHOULD NOT make any assumptions about this relationship, especially 192 regarding security issues. 194 References 196 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 197 RFC 1591, March 1994. 199 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 200 Internet Mail Extensions (MIME) Part Four: Registration 201 Procedures", BCP 13, RFC 2048, November 1996. 203 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 204 Requirement Levels", BCP 14, RFC 2119, March 1997. 206 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 207 Resource Identifiers (URI): Generic Syntax", RFC 2396, 208 August 1998. 210 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 211 Types", RFC 3023, January 2001. 213 Author's Address 215 Mark Nottingham 217 EMail: mailto:mnot@pobox.com 219 Appendix A. Acknowledgements 221 The following people gave input and feedback during the creation of 222 this document; Mark Baker, Don Box, Yaron Goland, Ted Hardie, John 223 Kemp, Graham Klyne, and David Orchard. All errors are the 224 responsibility of the author. 226 Intellectual Property Statement 228 The IETF takes no position regarding the validity or scope of any 229 intellectual property or other rights that might be claimed to 230 pertain to the implementation or use of the technology described in 231 this document or the extent to which any license under such rights 232 might or might not be available; neither does it represent that it 233 has made any effort to identify any such rights. Information on the 234 IETF's procedures with respect to rights in standards-track and 235 standards-related documentation can be found in BCP-11. Copies of 236 claims of rights made available for publication and any assurances of 237 licenses to be made available, or the result of an attempt made to 238 obtain a general license or permission for the use of such 239 proprietary rights by implementors or users of this specification can 240 be obtained from the IETF Secretariat. 242 The IETF invites any interested party to bring to its attention any 243 copyrights, patents or patent applications, or other proprietary 244 rights which may cover technology that may be required to practice 245 this standard. Please address the information to the IETF Executive 246 Director. 248 Full Copyright Statement 250 Copyright (C) The Internet Society (2003). All Rights Reserved. 252 This document and translations of it may be copied and furnished to 253 others, and derivative works that comment on or otherwise explain it 254 or assist in its implementation may be prepared, copied, published 255 and distributed, in whole or in part, without restriction of any 256 kind, provided that the above copyright notice and this paragraph are 257 included on all such copies and derivative works. However, this 258 document itself may not be modified in any way, such as by removing 259 the copyright notice or references to the Internet Society or other 260 Internet organizations, except as needed for the purpose of 261 developing Internet standards in which case the procedures for 262 copyrights defined in the Internet Standards process must be 263 followed, or as required to translate it into languages other than 264 English. 266 The limited permissions granted above are perpetual and will not be 267 revoked by the Internet Society or its successors or assignees. 269 This document and the information contained herein is provided on an 270 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 271 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 272 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 273 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 274 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 276 Acknowledgment 278 Funding for the RFC Editor function is currently provided by the 279 Internet Society.