Protocol: attribute selection

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

>   - attributes: A list of the attributes to be returned from each
>     entry which matches the search filter. LDAPString values of this
>     field are constrained to the following Augmented Backus-Naur Form
>     ([ABNF]):
>     
>     attributeSelection = noattrs /
>                         *( attributedescription / specialattr )       

This means a value of the SEQUENCE may be the concatenation of zero
or more (attributedescription / specialattr) (as opposed to the SEQUENCE
having multiple values, each either an attributedescription or specialattr.
Since each value is an attributeSelection, the list can contain multiple
"*" and "1.1".  Also, noattrs is now pretty special.

I suggest the ABNF be replaced:
    attributeSelection = attributedescription / selectionspecial
    selectionspecial = noattrs / alluserattrs
    noattrs = %x31.2E.31 ; "1.1"
    alluserattrs = %x2A ; asterisk ("*")

>     There are two special values which may be used: an empty list with
>     no attributes, and the attribute description string "*".         

Aside from the above, the term "two special values" here is confusing
as in one case is an empty SEQUENCE and the is *any* SEQUENCE which     
contains attrspec.  I suggest s/two special values/three special cases/
and then use bullet list (or numbered list) to enumerate each case.  E.g.,

  There are two special values which may be used: an empty list with   
    - an empty list,
    - a list containing "*" (and zero or more attributedescriptions), and
    - a list containing only "1.1".
      
>     Both of
>     these signify that all user attributes are to be returned. (The   
>     "*" allows the client to request all user attributes in addition  
>     to any specified operational attributes).             
      
  An empty list requests the return of all user attributes.  A list
  containing "*" requests all user attributes in addition             
  to other listed (operational) attributes.  A list containing         
  only "1.1" indicates that no values are to be returned.  (Note:
  if "1.1" is provided with other values, the "1.1" value is ignored.)

>     Attributes MUST NOT be named more than once in the list, and are

s/Attributes/Attribute (or specials)/ but...

This "MUST NOT" seems a bit too harsh.  No real harm (except
in bandwidth constrained environments) is caused by listing an
attribute description (or special) multiple times.  And this seems to
prohibit requests which list the attribute multiple times by different
attributedescription strings, e.g., once by each NAME and once by OID.
I've seen many clients which ask for attribute by multiple descriptors,
as by "cn" and "commonName".

I suggest this reworded to say that redundant values are ignored.

Kurt