We should stop using attribute descriptions
for this purpose.
You rtaised this issue some time ago and the
problem seemed to be that RFC 2251 allowed '*' to appear in an attribute
description (contrary to the semantics). Kurt introduced '+' and continues to
expand it.
The statement one would like to make is that
none of these uses are appropriate. But RFC 2251 already argues against
this.
So, ... where do you draw the
line?
Ron
I'm worried that
using SearchRequest.attributes to specify transfer encodings is going to cause
problems.
The draft uses an
attribute description option to allow one to request a search return attribute
to be encoded in a particular way (<attr>;transfer-<xferopt>). It
goes further to allow "all user attrs transferred as..."
(*;transfer-<xferopt>). Other specification s have proposed and are
proposing other tricks with attribute description options (+ specifies "all
operational attrs"), (+country specifies "all user attributes allowed by the
country object class").
The problem is
that we have a single mechanism (attribute description option) to specify
disparate features. The way in which these disparate features work together (I
fear) will be overlooked and under specified. For example, as soon as one sees
that *;transfer-ber is available, they want to use +;transfer-ber, or
+country;transfer-ber.
We can either
address this by adding some more statements to the extensions considerations
document, or just stop using attribute description options and start using
controls.
Jim
|