;binary and *, take 2.

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

I was recently reviewing RFC 2252 and came across this statement: 
   Clients which request that all attributes be returned
   from entries MUST be prepared to receive values in
   binary (e.g. userCertificate;binary), and SHOULD NOT
   simply display binary or unrecognized values to users.

(This statement needs to be moved to the [Protocol] section
detailing the binary transfer option.)

Given this MUST, I'd like to revise my previous suggestion:

There needs to a clarification regarding transfer encoding
to use when the attribute was not requested by attribute
description.  E.g., by * or an empty attribute list.

I suggest that if "foo" is to returned (when not requested
by attribute description), that the server is to use the
"native" transfer encoding if the server supports such for
that attribute.  Otherwise, if the server is able to generate
;binary for the attribute, the server is to return the
attribute using ;binary.  Otherwise, the attribute is
not to be returned.

The last statement is required as clients are not required
to treat attribute descriptions containing unrecognized
options as unrecognized.  That is, they may simply treat
the attribute description with one or more unrecognized
options as a (indirect) subtype of the attribute description
with the same attribute type and no options.

Additionally, the TS should say that clients MUST NOT
expect any particular transfer encoding of attributes
which are not requested by attribute description.  Where
a client desires a particular transfer encoding, including
the native encoding, the client SHOULD request the
attribute using an attribute description indicating
the desired transfer encoding.

Kurt