Re: interoperability of ;binary

["Jim Sermersheim" <jimse@novell.com>]

Supposing that we do away with ;binary, would that imply that there must be string encodings for all syntaxes? I don't like that. Any time you stringify a complex syntax you introduce delimiters. Then you have to escape occurrences of those delimiters in surrounding octet strings. It's much easier to just say that some syntaxes are always BER encoded (reagrdless of ;binary).

I'd personaly rather make a distinction between subtyping and non-subtyping options so we can leave the door open for tranfer options.

If we remove the feature, and retain the subtyping rules, how would the feature be re-introduced later? 

Jim

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 4/2/01 8:21:59 PM >>>
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