Subject: Re: interoperability of ;binary

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 02 Apr 2001 19:21:59 -0700

As raised at IETF#50, the current specification of ;binary
is not implementable in a manner that can satisfy the
requirements of the technical specification.  In particular,
the following two requirements appear to be counter to each
other.

  The presence or absence of the "binary" option only
  affects the transfer of attribute values in protocol;
  servers store any particular attribute in a single format.

  An AttributeDescription with one or more options is
  treated as a subtype of the attribute type without
  any options.

Even if we were to remove the latter requirement somehow,
there is still the multiple independently developed
interoperable implementation question in regards to the
other requirements of ";binary" transfer.  I concur with
Leif that it this may be difficult depending on the
criteria is used.

At IETF#50, one approach to resolving the subtyping issue
caused by the existence of the ";binary" option is to
introduce multiple kinds of attribute subtype options.  I
believe that this approach would require significant re-
engineering of the attribute description feature.  I am
concerned that the "fix" could be viewed as a "new feature".

Often the most appropriate "fix" at this stage in the standards
process is to remove the feature from the specification and
then reintroducing a "new feature" as an extension.

In this particular case, I suggest we consider removing the
";binary" transfer option from the specification and all
schema elements dependent on it, including: certificate,
userCertificate, and strongAuthenticationUser.  Then I suggest
reintroduction of these schema elements with alternative
string encodings as was done for LDAPv2 (RFC 2559).

Comments?

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Tue, 03 Apr 2001 10:07:40 -0400

> string encodings as was done for LDAPv2 (RFC 2559).

A string encoding of a certificate is not useful unless it is fully
reversible without loss (because PKI applications need access to the
original DER certificate).  So why bother?  The ;binary option as it is
used today for transfer of attribute values such as those of type
userCertificate is widely deployed and useful.  I would prefer that we
try a little harder to clarify the RFCs than remove this feature.

-Mark Smith
 Netscape

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 03 Apr 2001 07:52:11 -0700

At 10:07 AM 4/3/01 -0400, Mark C Smith wrote:
>original DER certificate).

Which is what RFC 2559 provides for LDAPv2, no options required.

-- Kurt