[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LDAP ISSUE
"Ramsay, Ron" wrote:
>
> How can you display an unknown keyword?
>
> The keyword comes out just fine, but the value? The assumption in LDAPv2 was
> that all values are encoded as printable (ASCII) strings, so your idea would
> work fine here. Now that we are in the modern world, though, some care must
> be taken with values. It would seem more appropriate to ignore unrecognised
> attributes, rather than displaying them.
>
Ron
good point. But is it worse to throw something away or to display what
youve got to the user, in the offchance that it might be useful. I think
the latter is more preferrable. As a case in point, a well known Windows
LDAP client that retrieves information but times out before everything
is recieved, throws it all away and displays a time out error to the
user, whereas another competing LDAP client displays what its got as
well as the time out message.
David
> Ron.
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@xxxxxxxxxxxxx]
> Sent: Tuesday, 23 July 2002 21:08
> To: steve.hanna@xxxxxxxxxxxx
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: LDAP ISSUE
>
> Steve Hanna wrote:
> >
> > David Chadwick wrote:
> > >we have two cases here.
> >
>
> Steve
>
> sorry for the late reply, but I was travelling in Japan all the week
> after the IETF meeting.
>
> > What about the case where a server returns a keyword to a
> > client that doesn't understand it?
>
> This is exactly why LDAP invented the use of keywords. The argument is
> that clients who dont understand the new attribute type, if it is
> identified by an object identifiers then displaying these OIDs to the
> users is pointless. However, if an unknown attribute is identified by an
> unknown keyword e.g. Pseudonymn is returned to the client, it simply
> displays it to the human user as is, in anticipation that it will make
> sense to the user. Certainly the keyword will make more sense to the
> human than the OID. Thus your third case above is one that actually
> supports the use of keywords rather than OIDs.
>
> >I agree that you can define
> > new keywords if all the software is updated or reconfigured
> > whenever a new keyword is defined. But this isn't realistic.
> >
>
> Its just as realistic as reconfiguring the software when a new attribute
> OID is defined. The whole point of LDAP using keywords was that unknown
> keywords were easier for dumb clients to handle than unknown OIDs.
>
> >
> > We agree that OIDs are the best solution for the on-the-wire
> > protocol.
>
> Actually I just gave an example when they werent!. But if we had a clean
> sheet for defining the LDAP protocol I would never have suggested
> inventing keywords and would have stuck with OIDs to be compatible with
> X.500. But there are many folk who think that keywords in protocol are
> far preferrable all the time to OIDs, since it makes debugging much
> easier (e.g. would you prefer to see 1.2.986.2345.26.3.4.67 or ssNumber
> when it occurs in protocol).
>
> >The best way forward seems clear to me. Don't define
> > new keywords to be used on the wire. Can you provide any reason
> > why it would be good to define more keywords?
> >
>
> Yes I just have done above. Could you also answer my point that already
> more than 50 keywords exist, and servers know how to map these into
> attribute types (and OIDs) when they exist in requests for attributes,
> but not when they exist in DNs. Can you explain why this situation is
> tenable?
>
> > >But now PKIX has defined some new attributes for use
> > >in DNs, and therefore the keywords for these should also be supported.
> >
> > Following that logic, we'll have to add new keywords whenever
> > anyone comes up with another attribute. Each keyword will
> > introduce another potential compatibility issue. That sounds
> > pretty undesirable to me.
> >
>
> No so, if the keyword is registered when the new attribute OID is
> registered, then both will appear at the same time.
>
> David
>
> > Thanks,
> >
> > Steve
>
> --
> *****************************************************************
>
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: +44 161 295 5351 Fax +44 01484 532930
> Mobile: +44 77 96 44 7184
> Email: D.W.Chadwick@xxxxxxxxxxxxx
> 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
> PGP Key ID is 0xBC238DE5
>
> *****************************************************************
--
*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351 Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@xxxxxxxxxxxxx
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
PGP Key ID is 0xBC238DE5
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@xxxxxxxxxxxxx
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard