idnits 2.17.1 draft-cridland-acap-vendor-registry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2244, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2244, updated by this document, for RFC5378 checks: 1997-11-01) -- 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 (Oct 22, 2010) is 4933 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft Isode Limited 4 Updates: 2244 (if approved) Oct 22, 2010 5 Intended status: Standards Track 6 Expires: April 25, 2011 8 The Internet Assigned Number Authority (IANA) Application Configuration 9 Access Protocol (ACAP) Vendor Subtrees Registry 10 draft-cridland-acap-vendor-registry-02 12 Abstract 14 The original ACAP specification included a vendor registry now used 15 in other protocols. This document updates the description of this 16 registry, removing the need for a direct normative reference to ACAP, 17 and removing ambiguity. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 25, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Conventions used in this document . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Vendor Subtree Registry . . . . . . . . . . . . . . . . . . 3 56 3.1. Internationalization . . . . . . . . . . . . . . . . . . . 4 57 3.2. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Changes from RFC 2244 . . . . . . . . . . . . . . . . . . . 6 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Example Registration . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [KEYWORDS]. 75 Formal Syntax are to be considered normative, and are specified using 76 [ABNF]. Where a formal syntax and the prose are in conflict, the 77 formal syntax takes precedence. 79 2. Introduction 81 The [ACAP] specification includes the specification and creation of 82 the ACAP Vendor Registry, and this registry has subsequently been 83 reused by several specifications, including both [ANNOTATE] and 84 [METADATA], and is proving to be a useful mechanism for namespacing 85 various names to within a specific vendor's scope. 87 The use of textual rather than numeric identifiers for vendors 88 benefits engineers and operators who are diagnosing protocol problems 89 by allowing them some possibility of identifying the origin of a 90 vendor attribute without having to look it up in a registry (although 91 that remains a necessary fallback). As such engineers and operators 92 already have to be familiar with international technical English to 93 diagnose textual protocol problems, the restriction to ASCII may help 94 and is not believed to harm that intended use. Exposure of vendor 95 attributes directly in end-user user interfaces was not an intended 96 use of the registry. 98 This document merely updates the registry to reduce ambiguity in the 99 original specification, and dissociates it from the original document 100 in all but name, allowing easier referencing. It replaces section 101 7.4 and portions of section 4, particularly 4.3, of [ACAP]. 103 3. The Vendor Subtree Registry 105 A Vendor Token is a UTF-8 string beginning with "vendor.", and 106 followed by the name of the company or product. This name MUST NOT 107 contain any slash character, period, or the percent and asterisk 108 characters typically used as wildcards. 110 Following this may be names, separated from the Vendor Token by a 111 period, which need not be registered, thus forming a complete Vendor 112 Name. 114 3.1. Internationalization 116 Vendor Tokens are able to contain any valid Unicode codepoint, 117 encoded as [UTF-8], except the special characters. Since the 118 publication of [ACAP], however, concerns have been raised on the 119 handling and comparison of full Unicode strings, and therefore this 120 specification restricts the current registrations to the ASCII subset 121 of UTF-8. 123 Furthermore, characters such as ASCII control characters, most 124 whitespace, and quotes are likely to be confusing and have been 125 similarly restricted. 127 Therefore, this document allows only ASCII letters, digits, the 128 hyphen, and space to be used (the ABNF production 129 in Section 3.2). 131 At the time of publication of this document, no existing 132 registrations violate the new restricted syntax on characters allowed 133 in registrations. [ACAP] required all Vendor Tokens to be registered 134 with IANA, so the new restriction is not believed to introduce any 135 interoperability issue. 137 Finally, note that this document does not change the requirement on 138 processors to accept other non-ASCII Unicode codepoints in Vendor 139 Tokens (the ABNF production in Section 3.2). 141 3.2. Formal Syntax 143 This syntax draws upon productions found within [ABNF] and [UTF-8]. 144 Productions replace those in section 4.3 of [ACAP]. 146 vendor-name = vendor-token *("." name-component) 148 name-component = *(name-char / UTF8-2 / UTF8-3 / UTF8-4) 150 name-char = %x01-24 / %x26-29 / %x2B-2D / %x30-7F 151 ;; ASCII-range characters not including ".", 152 ;; "/", "%", or "*". 154 vendor-token = "vendor." vendor-tag 155 ;; MUST be registered with IANA 157 vendor-tag = iana-vendor-tag / possible-vendor-tag 159 iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-") 160 ;; This production represents 161 ;; allowed forms for registrations 162 ;; under the rules specified in this 163 ;; document. 165 possible-vendor-tag = name-component 166 ;; This production represents what 167 ;; applications and specifications 168 ;; MUST be able to accept. 170 3.3. Examples 172 A company Example Ltd might register the Subtree "vendor.example". 173 This means it may use "vendor.example", or any name at all beginning 174 "vendor.example.", such as "vendor.example.product". 176 These names might be used in several protocols, and are reserved in 177 all the relevant protocols, so "vendor.example" might be an ACAP 178 dataset class name, and "/vendor/vendor.example" might be a tree of 179 IMAP ANNOTATE entries. 181 Example Ltd is free to use either "vendor.example", and group 182 specific products under it using the relevant protocol's hierarchy - 183 perhaps "/shared/vendor/vendor.example/product", or using more 184 specific names, such as "/shared/vendor/vendor.example.product". 186 Note that the solidus ("/") characters in the examples above are 187 protocol delimiters which are themselves not part of the vendor token 188 itself. 190 3.4. Changes from RFC 2244 192 This non-normative section details changes from RFC 2244's original 193 specification of the registry. 194 o Vendor tokens are restricted to ASCII for registration purposes. 195 o Clarifications that "vendor." means 196 "vendor.company name" or "vendor.product name" - "vendor.company/ 197 product" is and always has been illegal. 198 o Made "vendor.company" a name in its own right - RFC 2244 only 199 refers to a prefix of "vendor.company.". 200 o Added example registration, in line with [EXAMPLES]. 202 4. IANA Considerations 204 This specification updates the IANA registry named the ACAP Vendor 205 Subtrees Registry. IANA is requested to update the registry to point 206 at this document. 208 Vendors may reserve a portion of the ACAP namespace, which is also 209 used as the namespace for several other protocols, for private use. 210 Vendor Names are reserved for use by that company or product, 211 wherever used, once registered. Registration is on a first come, 212 first served basis. Whenever possible, private attributes and 213 classes should be eschewed in favour of improving interoperable 214 protocols. 216 Vendors may only use names conforming to iana-vendor-tag at the 217 current time, future revisions of this specification may change this. 219 To: iana@iana.org 220 Subject: Registration of ACAP vendor subtree 222 Private Prefix: vendor.name 224 Person and email address to contact for further information: 226 (company names and addresses should be included where appropriate) 228 4.1. Example Registration 230 IANA is requested to add the following registration, for use by 231 specification authors in examples, similarly to the domains specified 232 in [EXAMPLES]: 234 To: iana@iana.org 235 Subject: Registration of ACAP vendor subtree 237 Private Prefix: vendor.example 239 Person and email address to contact for further information: 241 Dave Cridland 243 5. Security Considerations 245 There are no known security issues with this registry. Individual 246 protocols using vendor subtree names may have security issues, and 247 the introduction of Unicode has in itself security implications - the 248 restriction of this is thought to mitigate these. 250 6. Acknowledgements 252 Thanks must go to Chris Newman, John Myers, and the other designers 253 of ACAP for the initial creation of the registry. Thanks also to 254 Alexey Melnikov for advice on this revision. 256 7. References 258 7.1. Normative References 260 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 261 Specifications: ABNF", STD 68, RFC 5234, January 2008. 263 [ACAP] Newman, C. and J. Myers, "ACAP -- Application 264 Configuration Access Protocol", RFC 2244, November 1997. 266 [KEYWORDS] 267 Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, March 1997. 270 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 271 10646", STD 63, RFC 3629, November 2003. 273 7.2. Informative References 275 [ANNOTATE] 276 Daboo, C. and R. Gellens, "Internet Message Access 277 Protocol - ANNOTATE Extension", RFC 5257, June 2008. 279 [EXAMPLES] 280 Eastlake, D. and A. Panitz, "Reserved Top Level DNS 281 Names", BCP 32, RFC 2606, June 1999. 283 [METADATA] 284 Daboo, C., "The IMAP METADATA Extension", RFC 5464, 285 February 2009. 287 Author's Address 289 Dave Cridland 290 Isode Limited 291 5 Castle Business Village 292 36, Station Road 293 Hampton, Middlesex TW12 2BX 294 GB 296 Email: dave.cridland@isode.com