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

Re: (ITS#4100) userCertificate vs. userCertificate;binary when deleting attribute

At 02:18 PM 11/3/2005, Michael Ströder wrote:
>Kurt D. Zeilenga wrote:
>> I've added a test case to test021 to verify proper
>> behavior of modify/delete of the userCertificate;binary
>> attribute.  You can confirm this result by running
>> test021 in HEAD or RE23.
>> Modify/delete of userCertificate should be expected to
>> fail and does.
>Sorry for probably beating a dead horse:
>But was this really the outcome of the ;binary discussion? It makes life
>of a LDAP client developer even more miserable when creating input forms
>just with schema knowledge. There's no valuable information in the sub
>schema about ;binary.

I would argue that allowing a special case of

        dn: ....
        changetype: modify
        modify: delete
        delete: userCertificate

would actually cause far more user and/or developer confusion.
In most every other possible modify operation, userCertificate;binary
MUST be used per RFC 2256.  A user or developer seeing that
this special case works, would likely try 'userCertificate'
in one of the cases where it is clearly invalid.

As far as forms go, one has to know the option(s) are required.
To assume the option can be removed in this or other special cases
would require special knowledge of the schema and the option.
Note with most other options (all tagging options), if you add
a value of "cn;x-foo" you must delete all values using "cn;x-foo".
Deleting "cn" MUST NOT delete "cn;x-foo" (assuming x-foo is a
tagging option).

And as far as creating input forms go, I would assume one
would have knowledge of the attribute they are deleting.
As the server certainly MUST return the attribute as
userCertificate;binary, no schema knowledge is actually
required to know ;binary must appear to delete it.
One simply echoes the attribute description as returned
by the server.

I note there are very few LDAP attribute value syntaxes that
require ;binary.  So even if you go the schema route, it's
not like you have to special case endless number of
syntaxes.  IIRC, there are 4 such standard-track syntaxes.
Of course, there could be endless locally defined syntaxes,
but I suspect there are few... anyone with any brains
would avoid ;binary on anything new (as suggested by
the revised ;binary specification).

Anyways, failing on 'userCertificate' here is, at least,
the intended behavior.