rfc2244.txt

中、英文RFC文档大全打包下载完全版 .

   name, then one SHOULD be obtained from the specified mechanism or
   requested from the user as appropriate.  If a user name is supplied
   without an authentication mechanism then ";AUTH=*" is assumed.

   The ";AUTH=" authentication parameter is interpreted as described in
   the IMAP URL Scheme [IMAP-URL].

   Note that if unsafe or reserved characters such as " " or ";" are
   present in the user name or authentication mechanism, they MUST be
   encoded as described in the URL specification [BASIC-URL].

3.2.2.   Relative ACAP URLs

   Because ACAP uses "/" as the hierarchy separator for dataset paths,
   it works well with the relative URL rules defined in the relative URL
   specification [REL-URL].

   The <aauth> grammar element is considered part of the user name for
   purposes of resolving relative ACAP URLs.

   The base URL for a relative URL stored in an attribute's value is
   formed by taking the path to the dataset containing that attribute,
   appending a "/" followed by the entry name of the entry containing
   that attribute followed by "/".

3.3.     Contexts

   A context is subset of entries in a dataset or datasets, created by a
   SEARCH command with a MAKECONTEXT modifier.  Context names are
   client-generated strings and must not start with the slash ('/')
   character.

   When a client creates a context, it may request automatic
   notification of changes.  A client may also request enumeration of
   entries within a context.  Enumeration simplifies the implementation
   of a "virtual scrollbar" by the client.

   A context exists only within the ACAP session in which it was
   created.  When the connection is closed, all contexts associated with
   that connection are automatically discarded.  A server is required to
   support at least 100 active contexts within a session.  If the server
   supports a larger limit it must advertise it in a CONTEXTLIMIT
   capability.








Newman & Myers              Standards Track                    [Page 14]

RFC 2244                          ACAP                     November 1997


3.4.     Comparators

   A comparator is a named function which takes two input values and can
   be used to perform one or more of four comparison operations:
   ordering, equality, prefix and substring matching.

   The ordering operation is used both for the SORT search modifier and
   the COMPARE and COMPARESTRICT search keys.  Ordering comparators can
   determine the ordinal precedence of any two values.  When used for
   ordering, a comparator's name can be prefixed with "+" or "-" to
   indicate that the ordering should be normal order or reversed order
   respectively.  If no prefix is included, "+" is assumed.

   For the purpose of ordering, a comparator may designate certain
   values as having an undefined ordinal precedence.  Such values always
   collate with equal value after all other values regardless of whether
   normal or reversed ordering is used.  Unless the comparator
   definition specifies otherwise, multi-values and NIL values have an
   undefined ordinal precedence.

   The equality operation is used for the EQUAL search modifier, and
   simply determines if the two values are considered equal under the
   comparator function.  When comparing a single value to a multi-value,
   the two are considered equal if any one of the multiple values is
   equal to the single value.

   The prefix match operation is used for the PREFIX search modifier,
   and simply determines if the search value is a prefix of the item
   being searched.  In the case of prefix search on a multi-value, the
   match is successful if the value is a prefix of any one of the
   multiple values.

   The substring match operation is used for the SUBSTRING search
   modifier, and simply determines if search value is a substring of the
   item being searched.  In the case of substring search on a multi-
   value, the match is successful if the value is a substring of any one
   of the multiple values.

   Rules for naming and registering comparators will be defined in a
   future specification.  Servers MUST respond to unknown or improperly
   used comparators with a BAD command completion result.










Newman & Myers              Standards Track                    [Page 15]

RFC 2244                          ACAP                     November 1997


   The following comparators are defined by this standard and MUST be
   implemented:

      i;octet
           Operations: Ordering, Equality, Prefix match, Substring match

           For collation, the i;octet comparator interprets the value of
           an attribute as a series of unsigned octets with ordinal
           values from 0 to 255.  When ordering two strings, each octet
           pair is compared in sequence until the octets are unequal or
           the end of the string is reached.  When collating two strings
           where the shorter is a prefix of the longer, the shorter
           string is interpreted as having a smaller ordinal value.  The
           "i;octet" or "+i;octet" forms collate smaller ordinal values
           earlier, and the "-i;octet" form collates larger ordinal
           values earlier.

           For the equality function, two strings are equal if they are
           the same length and contain the same octets in the same
           order.  NIL is equal only to itself.

           For non-binary, non-nil single values, i;octet ordering is
           equivalent to the ANSI C [ISO-C] strcmp() function applied to
           C string representations of the values.  For non-binary,
           non-nil single values, i;octet substring match is equivalent
           to the ANSI C strstr() function applied to the C string
           representations of the values.

      i;ascii-casemap
           Operations: Ordering, Equality, Prefix match, Substring match

           The i;ascii-casemap comparator first applies a mapping to the
           attribute values which translates all US-ASCII letters to
           uppercase (octet values 0x61 to 0x7A are translated to octet
           values 0x41 to 0x5A respectively), then applies the i;octet
           comparator as described above.  With this function the values
           "hello" and "HELLO" have the same ordinal value and are
           considered equal.

      i;ascii-numeric
           Operations: Ordering, Equality

           The i;ascii-numeric comparator interprets strings as decimal
           positive integers represented as US-ASCII digits.  All values
           which do not begin with a US-ASCII digit are considered equal
           with an ordinal value higher than all non-NIL single-valued





Newman & Myers              Standards Track                    [Page 16]

RFC 2244                          ACAP                     November 1997


           attributes.  Otherwise, all US-ASCII digits (octet values
           0x30 to 0x39) are interpreted starting from the beginning of
           the string to the first non-digit or the end of the string.


3.5.     Access Control Lists (ACLs)

   An access control list is a set of identifier, rights pairs used to
   restrict access to a given dataset, attribute or attribute within an
   entry.  An ACL is represented by a multi-value with each value
   containing an identifier followed by a tab character followed by the
   rights.  The syntax is defined by the "acl" rule in the formal syntax
   in section 8.

   Identifier is a UTF-8 string.  The identifier "anyone" is reserved to
   refer to the universal identity (all authentications, including
   anonymous).  All user name strings accepted by the AUTHENTICATE
   command to authenticate to the ACAP server are reserved as
   identifiers for the corresponding user.  Identifiers starting with a
   slash ("/") character are reserved for authorization groups which
   will be defined in a future specification.  Identifiers MAY be
   prefixed with a dash ("-") to indicate a revocation of rights.  All
   other identifiers have implementation-defined meanings.

   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled.  Letters are reserved for "standard" rights, listed
   below.  The set of standard rights may only be extended by a
   standards-track or IESG approved experimental RFC.  Digits are
   reserved for implementation or site defined rights.  The currently
   defined standard rights are:

   x - search (use EQUAL search key with i;octet comparator)
   r - read (access with SEARCH command)
   w - write (modify with STORE command)
   i - insert (perform STORE on a previously NIL value)
   a - administer (perform SETACL or STORE on ACL attribute/metadata)

   An implementation may force rights to always or never be granted.  In
   particular, implementations are expected to grant implicit read and
   administer rights to a user's personal dataset storage in order to
   avoid denial of service problems.  Rights are never tied, unlike the
   IMAP ACL extension [IMAP-ACL].

   It is possible for multiple identifiers in an access control list to
   apply to a given user (or other authentication identity).  For
   example, an ACL may include rights to be granted to the identifier
   matching the user, one or more implementation-defined identifiers



Newman & Myers              Standards Track                    [Page 17]

RFC 2244                          ACAP                     November 1997


   matching groups which include the user, and/or the identifier
   "anyone".  These rights are combined by taking the union of all
   positive rights which apply to a given user and subtracting the union
   of all negative rights which apply to that user.  A client MAY avoid
   this calculation by using the MYRIGHTS command and metadata items.

   Each attribute of each entry of a dataset may potentially have an
   ACL.  If an attribute in an entry does not have an ACL, then access
   is controlled by a default ACL for that attribute in the dataset, if
   it exists.  If there is no default ACL for that attribute in the
   dataset, access is controlled by a default ACL for that dataset.  The
   default ACL for a dataset must exist.

   In order to perform any access or manipulation on an entry in a
   dataset, the client must have 'r' rights on the "entry" attribute of
   the entry.  Implementations should take care not to reveal via error
   messages the existence of an entry for which the client does not have
   'r' rights.  A client does not need access to the "subdataset"
   attribute of the parent dataset in order to access the contents of a
   dataset.

   Many of the ACL commands and responses include an "acl object"
   parameter, for specifying what the ACL applies to.  This is a
   parenthesized list.  The list contains just the dataset name when
   referring to the default ACL for a dataset.  The list contains a
   dataset name and an attribute name when referring to the default ACL
   for an attribute in a dataset.  The list contains a dataset name, an
   attribute name, and an entry name when referring to the ACL for an
   attribute of an entry of a dataset.


3.6.     Server Response Codes

   An OK, NO, BAD, ALERT or BYE response from the server MAY contain a
   response code to describe the event in a more detailed machine
   parsable fashion.  A response code consists of data inside
   parentheses in the form of an atom, possibly followed by a space and
   arguments.  Response codes are defined when there is a specific
   action that a client can take based upon the additional information.
   In order to support future extension, the response code is
   represented as a slash-separated hierarchy with each level of
   hierarchy representing increasing detail about the error.  Clients
   MUST tolerate additional hierarchical response code detail which they
   don't understand.

   The currently defined response codes are:





Newman & Myers              Standards Track                    [Page 18]

RFC 2244                          ACAP                     November 1997


      AUTH-TOO-WEAK
           This response code is returned on a tagged NO result from an
           AUTHENTICATE command.  It indicates that site security policy
           forbids the use of the requested mechanism for the specified
           authentication identity.

      ENCRYPT-NEEDED
           This response code is returned on a tagged NO result from an
           AUTHENTICATE command.  It indicates that site security policy
           requires the use of a strong encryption mechanism for the
           specified authentication identity and mechanism.

      INVALID
           This response code indicates that a STORE command included
           data which the server implementation does not permit.  It
           MUST NOT be used unless the dataset class specification for
           the attribute in question explicitly permits enforced server
           validation.  The argument is the attribute which was invalid.

      MODIFIED
           This response code indicates that a conditional store failed
           because the modtime on the entry is later than the modtime
           specified with the STORE command UNCHANGEDSINCE modifier.
           The argument is the entry which had been modified.

      NOEXIST
           This response code indicates that a search or NOCREATE store
           failed because a specified dataset did not exist.  The
           argument is the dataset which does not exist.

      PERMISSION
           A command failed due to insufficient permission based on the
           access control list or implicit rights.  The argument is the
           acl-object which caused the permission failure.

      QUOTA
           A STORE or SETACL command which would have increased the size
           of the dataset failed due to insufficient quota.