IETF#52: attribute description options

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Attribute descriptions where discussed in significant detail
during the LDAPbis session at IETF#52.  As the discussions
easy get fogged by unclear terminology, the following is an
attempt to clarify the engineering team's proposal as presented
at IETF#52 and to recommend next steps.

  An attribute held in the directory consists of an attribute
  description (consisting of an attribute type and zero or more
  options) and one or more values.  Not all options can be
  associated with attributes held in the directory.

  An attribute description which contains mutually exclusive
  options shall to be treated as unrecognized.  That is,
  "cn;binary;gser" (where ;binary and ;gser are mutually exclusive)
  is to be treated as an unrecognized attribute.

  There are multiple kinds of attribute description options.
  The technical specification details two kinds: tagging options
  (such as language tag options) and transfer options (such as
  ;binary).  Other documents may detail other kinds.

  An attribute with N tagging options is considered an direct
  subtype of all attributes of the same type and all but one of
  the N options.  If the type has a supertype, then the attribute
  is also considered a direct subtype of the attribute of the
  supertype and the N tagging options.  That is, cn;lang_de;lang_en
  is considered an direct subtype of cn;lang_de, cn;lang_en,
  and name;lang_de;lang_en (cn is a subtype of name).  Tagging
  options are never mutually exclusive and can be held in the
  directory.

  Transfer options are not held in the directory, they only
  affect the encoding used to transfer values.  The absence of
  a transfer option implies the native encoding.  Transfer
  options are mutually exclusive.  If an attribute is requested
  to be returned using a particular transfer encoding, that
  encoding is used for that attribute and its subtypes.  That
  is, requesting name;binary requests the attribute name and
  its subtypes (e.g., cn, sn, cn;lang_en, etc.) be returned
  using binary transfer.

  Clients SHOULD avoid requesting the return of attributes
  related to each other in the attribute subtyping hierarchy
  with different transfer encodings.  For example, requesting
  name;lang_en;binary and cn should be avoided as it ambiguous
  as to how cn;lang_en is to be transferred.  In such cases, the
  server's behavior is undefined (the server can return the
  values in either, neither, or both encodings).

  Other documents may specify other kinds of options.  These
  document must detail how new kinds of options relate to
  tagging and transfer options.  In particular, the document
  must describe how the options relation to the attribute
  subtyping hierarchy.

As there was (and likely still is) some lack of clarity as to
the engineering team's recommendation, the chair(s) have asked
Jim (the editor) to implement the engineering team's recommendation
in the next revision of the protocol I-D, then clarify as
appropriate based upon list discussions, then determine whether
the approach is consistent with WG consensus. 

Kurt