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

Re: matched values 05




Bruce Greenblatt wrote:
> 
> While I appreciate all of the hard work that has gone into the development
> of the control, I don't feel that it is a good idea.  So, I guess the time
> has come (again) for me to state my opinion about the Matched Values Only
> (MVO) control.  IMHO the MVO control as described in this draft is a
> negative.  Throughout its progression, it has grown increasingly more
> complex.  As I recall, it started out life as a simple boolean.
> 

Correct, this was so it could conform to the X.50O extension. But after
much discussion on the list we found that the X.500 solution was
deficient. Hence the use of a simple filter (which servers will already
have implemented for the Search operation). I propose to align the
future X.50O with this control under the X.500 alignment work item that
it now active.

> The problem that is solved is mostly due to poor schema and DIT structure
> design.  There is no reason to have so many attribute values in the
> attribute of an entry.  

I believe this is a fundamentally wrong statement. Sure, you can ensure
that no entry ever has more than single attribute values in it. But this
is not good DIT design, this is poor DIT design, as you are being forced
to bend the DIT to fit the LDAP protocol that is incapable of supporting
a more natural DIT design e.g. for a PKI I have to have several entries,
each containing one certificate, because LDAP cannot support a single
entry with multiple certificates. If you are interested in more details
about this and other LDAP limitations, I have a written a paper that is
currently under review for publication entitled "Deficiencies in LDAP
when used to support a PKI". Once the paper is accepted I will let you
have a copy if you wish.

>As an example of how to solve this problem, I wrote
> a draft that described an alternative way of storing certificates (alas, it
> has expired).  With more thought given to the schema and DIT structure
> design, existing protocol and simple matching rules can be used to solve
> the problem that this complex MVO control solves.
> 

Sure they can. Also, you can build a car with a hammer and nails if you
dont possess nuts, bolts and screws, but I would hardly call it good
design. Rather it is poor design forced upon you because of a lack of
proper tools.

> I don't think that the Section 4 adequately address the problems of the
> interaction with other controls.  I am not convinced that the MVO control
> acts independently of server side sorting.  It seems to me that attribute
> values that are used in the sorting process can be subsequently affected by
> the MVO control.
> 

Ok. Please tell me where the ID is deficient in this area and we will
fix it. I have attempted to cover the overlaps in this section, but if I
have missed something please provide a concrete example and we will fix
it.


David

> My recommendation would be to not progress this draft at all.  If it is to
> be progressed at all, it should go only as Experimental since the impact on
> existing controls has not been explored, and since there are simpler
> solutions to the problem it claims to solve.
> 
> Thanks,
> 
> Bruce Greenblatt
> 
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
> See my new Book on Internet Directories:
> http://www.phptr.com/ptrbooks/ptr_0139744525.html

-- 
*****************************************************************

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 790 167 0359
Email: D.W.Chadwick@salford.ac.uk
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J

*****************************************************************
begin:vcard 
n:Chadwick;David
tel;fax:+44 1484 532930
tel;home:+44 790 167 0359
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
x-mozilla-cpt:;-16144
fn:David Chadwick
end:vcard

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature