[Date Prev][Date Next]
RE: RFC2253bis: "a published table"
> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Volpers, Helmut
> Sent: Wednesday, 8 November 2000 20:07
> To: 'firstname.lastname@example.org'; Volpers, Helmut
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: RFC2253bis: "a published table"
> > -----Original Message-----
> > From: Steven Legg [mailto:email@example.com]
> > Sent: Mittwoch, 8. November 2000 07:18
> > To: 'Volpers, Helmut'
> > Cc: ietf-ldapbis@OpenLDAP.org
> > Subject: RE: RFC2253bis: "a published table"
> > The problem is if the member value (of DN syntax) contains an
> > ambiguous
> > attribute type name. Suppose I have a server with a schema that
> > defines an attribute type called employeeNumber, and that you also
> > have a server with a schema that defines an attribute type called
> > employeeNumber, but with a different OID and perhaps even a
> > syntax.
> That is a real problem. It should not happen.
There's nothing in LDAP to stop it happening. A prohibition on using
non-standard attribute names in LDAP string syntaxes (not just DNs)
would avoid the problem.
> Now suppose that some client wants to take a DN from your
> > namespace, e.g. cn=John Smith + employeeNumber=999, o=Foobar
> > Inc., c=de
> > and put it into a groupOfNames entry in my server. How is my server
> > to know that the employeeNumber attribute type name refers to the
> > type definition in your schema instead of the attribute of the same
> > name in my local schema ?
> I think for your server it refers to your local schema.
Which is exactly the wrong thing for my server to do in this case.
The BER encoding of the DN would have the wrong OID for the employeeNumber
attribute, i.e. it would be a different DN to the one intended.
> A sophisticated name to OID translation
> > function could take account of the context (i.e. o=Foobar
> Inc., c=de)
> I don't like it so much.
Nor do I.
> > in which the attribute name has been used, but there are other ways
> > in which foreign attribute names could be encountered where there
> > wouldn't be any useful context.
> What other ways do you mean ?
Well, anywhere that an attribute type name appears in an LDAP string
for an attribute syntax or assertion syntax. I was thinking particularly of
AttributeCertificateAssertion syntax, but values of
ObjectClassDescription, NameFormDescription, Guide, EnhancedGuide, among
are susceptible to a change of meaning by being copied from one server to
because of attribute type name ambiguity.
> > Regards,
> > Steven
> > [snip]
> > >
> > > Helmut
> > > >
> > > > Kurt
> > > >
> > > >
> > >