Isode Limited

5 Castle Business Village 36, Station Road Hampton Middlesex TW12 2BX GB dave.cridland@isode.com

Applications The original 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.

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 . Formal Syntax are to be considered normative, and are specified using . Where a formal syntax and the prose are in conflict, the formal syntax takes precedence.

The specification includes the specification and creation of the ACAP Vendor Registry, and this registry has subsequently been reused by several specifications, including both and , 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 4.3, of .

A Vendor Token is a UTF-8 string beginning with "vendor.", and 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.

Vendor Tokens are able to contain any valid Unicode codepoint, encoded as , except the special characters. Since the publication of , however, concerns have been raised on the handling and comparison of full Unicode strings, and 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 (the <iana-vendor-tag> 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. 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 <possible-vendor-tag> ABNF production in Section 3.2).

This syntax draws upon productions found within and . Productions replace those in section 4.3 of . 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.

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 dataset class name, and "/vendor/vendor.example" might be a tree of IMAP ANNOTATE entries. 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", or using more specific names, such as "/shared/vendor/vendor.example.product". Note that the solidus ("/") characters in the examples above are protocol delimiters which are themselves not part of the vendor token itself.

This non-normative section details changes from RFC 2244's original specification of the registry. Vendor tokens are restricted to ASCII for registration purposes. Clarifications that "vendor.<company/product name>" means "vendor.company name" or "vendor.product name" - "vendor.company/product" is and always has been illegal. Made "vendor.company" a name in its own right - RFC 2244 only refers to a prefix of "vendor.company.". Added example registration, in line with .

This specification updates the IANA registry named the ACAP Vendor Subtrees Registry. IANA is requested to update 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)

IANA is requested to add the following registration, for use by specification authors in examples, similarly to the domains specified in :

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 <dave.cridland@isode.com>

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.

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.

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK] Innosoft International, Inc.

1050 Lakes Drive West Covina CA 91790 US chris.newman@innosoft.com

Netscape Communications

501 East Middlefield Road Mail Stop MV-029 Mountain View CA 94043 US jgmyers@netscape.com

The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted. Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.</t><t> Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.</t><t> Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. This memo defines an Experimental Protocol for the Internet community. IBM

65 Shindegan Hill Road RR #1 Carmel NY 10512 US +1 914 276 1668 +1 914 784 3833 dee3@us.ibm.com

500 Stamford Dr. No. 310 Newark DE 19711 US +1 302 738 1554 buglady@fuschia.net

To reduce the likelihood of conflict and confusion, a few top level domain names are reserved for use in private testing, as examples in documentation, and the like. In addition, a few second level domain names reserved for use as examples are documented. The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS TRACK]