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