From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6075.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6075.txt (limited to 'doc/rfc/rfc6075.txt') diff --git a/doc/rfc/rfc6075.txt b/doc/rfc/rfc6075.txt new file mode 100644 index 0000000..7738ceb --- /dev/null +++ b/doc/rfc/rfc6075.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Cridland +Request for Comments: 6075 Isode Limited +Updates: 2244 December 2010 +Category: Standards Track +ISSN: 2070-1721 + + +The Internet Assigned Number Authority (IANA) Application Configuration + Access Protocol (ACAP) Vendor Subtrees Registry + +Abstract + + The original Application Configuration Access Protocol (ACAP) + specification included a vendor registry now used in other protocols. + This document updates the description of this registry, removing the + need for a direct normative reference to ACAP and removing ambiguity. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6075. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Cridland Standards Track [Page 1] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Conventions Used in This Document . . . . . . . . . . . . . . . 2 + 3. The Vendor Subtree Registry . . . . . . . . . . . . . . . . . . 3 + 3.1. Internationalization . . . . . . . . . . . . . . . . . . . 3 + 3.2. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.4. Changes from RFC 2244 . . . . . . . . . . . . . . . . . . . 5 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Example Registration . . . . . . . . . . . . . . . . . . . 6 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 + +1. Introduction + + The [ACAP] specification includes the specification and creation of + the ACAP Vendor Registry, and this registry has subsequently been + reused by several specifications, including both [ANNOTATE] and + [METADATA], and is proving to be a useful mechanism for namespacing + various names to within a specific vendor's scope. + + The use of textual rather than numeric identifiers for vendors + benefits engineers and operators who are diagnosing protocol problems + by allowing them some possibility of identifying the origin of a + vendor attribute without having to look it up in a registry (although + that remains a necessary fallback). As such, engineers and operators + already have to be familiar with international technical English to + diagnose textual protocol problems, the restriction to ASCII may help + and is not believed to harm that intended use. Exposure of vendor + attributes directly in end-user user interfaces was not an intended + use of the registry. + + This document merely updates the registry to reduce ambiguity in the + original specification and dissociates it from the original document + in all but name, allowing easier referencing. It replaces Section + 7.4 and portions of Section 4, particularly Section 4.3, of [ACAP]. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [KEYWORDS]. + + + + + +Cridland Standards Track [Page 2] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + + The formal syntax is to be considered normative and is specified + using [ABNF]. Where a formal syntax and the prose are in conflict, + the formal syntax takes precedence. + +3. The Vendor Subtree Registry + + A Vendor Token is a UTF-8 string that begins with "vendor." and that + is followed by the name of the company or product. This name MUST + NOT contain any slash character, period, or the percent and asterisk + characters typically used as wildcards. + + Following this may be names, separated from the Vendor Token by a + period, which need not be registered, thus forming a complete Vendor + Name. + +3.1. Internationalization + + Vendor Tokens are able to contain any valid Unicode codepoint, + encoded as [UTF-8], except the special characters. Since the + publication of [ACAP], however, concerns have been raised on the + handling and comparison of full Unicode strings; therefore, this + specification restricts the current registrations to the ASCII subset + of UTF-8. + + Furthermore, characters such as ASCII control characters, most + whitespace, and quotes are likely to be confusing and have been + similarly restricted. + + Therefore, this document allows only ASCII letters, digits, the + hyphen, and space to be used in registrations (the + ABNF production in Section 3.2). + + At the time of publication of this document, no existing + registrations violate the new restricted syntax on characters allowed + in registrations. [ACAP] required all Vendor Tokens to be registered + with IANA, so the new restriction is not believed to introduce any + interoperability issue. + + Finally, note that this document does not change the requirement on + processors to accept other non-ASCII Unicode codepoints in Vendor + Tokens (the ABNF production in Section 3.2). + + + + + + + + + + +Cridland Standards Track [Page 3] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + +3.2. Formal Syntax + + This syntax draws upon productions found within [ABNF] and [UTF-8]. + Productions replace those in Section 4.3 of [ACAP]. + + vendor-name = vendor-token *("." name-component) + + name-component = *(name-char / UTF8-2 / UTF8-3 / UTF8-4) + + name-char = %x01-24 / %x26-29 / %x2B-2D / %x30-7F + ;; ASCII-range characters not including ".", + ;; "/", "%", or "*". + + vendor-token = "vendor." vendor-tag + ;; MUST be registered with IANA + + vendor-tag = iana-vendor-tag / possible-vendor-tag + + iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-") + ;; This production represents + ;; allowed forms for registrations + ;; under the rules specified in this + ;; document. + + possible-vendor-tag = name-component + ;; This production represents what + ;; applications and specifications + ;; MUST be able to accept. + +3.3. Examples + + A company Example, Ltd. might register the Subtree "vendor.example". + This means it may use "vendor.example", or any name at all beginning + "vendor.example.", such as "vendor.example.product". + + These names might be used in several protocols, and are reserved in + all the relevant protocols, so "vendor.example" might be an ACAP + [ACAP] dataset class name, and "/vendor/vendor.example" might be a + tree of IMAP ANNOTATE entries [ANNOTATE]. + + Example, Ltd. is free to use either "vendor.example", and group + specific products under it using the relevant protocol's hierarchy -- + perhaps "/shared/vendor/vendor.example/product" annotation + [ANNOTATE], or using more specific names, such as "/shared/vendor/ + vendor.example.product" annotation. + + Note that the solidus ("/") characters in the examples above are + protocol delimiters that are themselves not part of the Vendor Token. + + + +Cridland Standards Track [Page 4] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + +3.4. Changes from RFC 2244 + + This non-normative section details changes from the original + specification of the registry in RFC 2244. + + o Vendor Tokens are restricted to ASCII for registration purposes. + + o Clarifications that "vendor." means + "vendor.company name" or "vendor.product name" - "vendor.company/ + product" is and always has been illegal. + + o Made "vendor.company" a name in its own right - RFC 2244 only + refers to a prefix of "vendor.company.". + + o Added example registration, in line with [EXAMPLES]. + +4. IANA Considerations + + This specification updates the IANA registry named the ACAP "Vendor + Subtrees" registry. IANA has updated the registry to point at this + document. + + Vendors may reserve a portion of the ACAP namespace, which is also + used as the namespace for several other protocols, for private use. + Vendor Names are reserved for use by that company or product, + wherever used, once registered. Registration is on a first come, + first served basis. Whenever possible, private attributes and + classes should be eschewed in favour of improving interoperable + protocols. + + Vendors may only use names conforming to iana-vendor-tag at the + current time; future revisions of this specification may change this. + + To: iana@iana.org + Subject: Registration of ACAP Vendor Subtree + + Private Prefix: vendor.name + + Person and email address to contact for further information: + + (company names and addresses should be included where appropriate) + + + + + + + + + + +Cridland Standards Track [Page 5] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + +4.1. Example Registration + + IANA is requested to add the following registration, for use by + specification authors in examples, similarly to the domains specified + in [EXAMPLES]: + + To: iana@iana.org + Subject: Registration of ACAP Vendor Subtree + + Private Prefix: vendor.example + + Person and email address to contact for further information: + + Dave Cridland + +5. Security Considerations + + There are no known security issues with this registry. Individual + protocols using Vendor Subtree names may have security issues, and + the introduction of Unicode has, in itself, security implications -- + the restriction of this is thought to mitigate these. + +6. Acknowledgements + + Thanks must go to Chris Newman, John Myers, and the other designers + of ACAP for the initial creation of the registry. Thanks also to + Alexey Melnikov for advice on this revision. + + +7. References + +7.1. Normative References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [KEYWORDS] + Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + + + + + +Cridland Standards Track [Page 6] + +RFC 6075 ACAP Vendor Subtrees Registry December 2010 + + +7.2. Informative References + + [ANNOTATE] + Daboo, C. and R. Gellens, "Internet Message Access + Protocol - ANNOTATE Extension", RFC 5257, June 2008. + + [EXAMPLES] + Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999. + + [METADATA] + Daboo, C., "The IMAP METADATA Extension", RFC 5464, + February 2009. + +Author's Address + + Dave Cridland + Isode Limited + 5 Castle Business Village + 36, Station Road + Hampton, Middlesex TW12 2BX + GB + + EMail: dave.cridland@isode.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cridland Standards Track [Page 7] + -- cgit v1.2.3