Re: ;binary migration solution

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Jim Sermersheim writes:
> The way the specification was written, the ;binary option is never
> stored with the value. it was only to be used to denote the transfer
> encoding format. By making the "native encoding" of userCertificate
> equivalent to the "binary" encoding, this makes "userCertificate" and
> "userCertificate;binary" equivalent. This is why I agreed with your
> proposal.

Well, I no longer agree with it, after reading David's comments.  I had
not understood how ;binary works.

I think it's better if it works just like it does today, except that it
no longer has any effect on encoding.  If I understand correctly, that
means: (pkix readers, sorry for the repeat)

- The "binary" option does nothing to encoding.
  Attribute syntaxes take care of encoding.
- The option is removed from attribute descriptions in LDAP
  operations, except
  (a) in attribute values (like DNs),
  (b) in places where options may not occur.
      I must check if (a) implies (b) so (b) can be skipped.
  Thus, attribute descriptions are stored without ;binary in
  the directory.
- If a search requested an attribute with the "binary" option,
  it is added to that attribute in the search result (if that
  attribute is returned).

Migration plan (maybe this should be added as an implementation note):

(1) Servers upgrade to the new spec, while clients continue
    using ;binary.
(2) When (1) has progressed far enough, clients quit using ;binary.
(3) When (2) has progressed far enough, ;binary is removed from
    the next revision of the standard which defines it, if/when a
    next revision happens.

-- 
Hallvard