[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: [ldapext] draft-legg-ldap-transfer-00



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
-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com]
Sent: Thursday, 17 July 2003 19:16
To: ldapext@ietf.org
Subject: [ldapext] draft-legg-ldap-transfer-00

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