Subject: Re: interoperability of ;binary

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 03 Apr 2001 00:18:51 -0600

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" <[email-masked]> 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

---

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

At 12:18 AM 4/3/01 -0600, Jim Sermersheim wrote:
>Supposing that we do away with ;binary, would that imply that there must be string encodings for all syntaxes?

Yes.  Some might be BER/DER string encodings as was done
in LDAPv2 for userCertificates (RFC2559).

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

Making a distinction in RFC2251bis scares me.  One has to
go down the path of whether there multiple kinds of subtyping
and non-subtyping options.  That is direct vs non-direct
subtyping options.  Or, transfer options which act like
subtyping options in some contexts but not in others.  We
end up having to redesign the feature, hence the protocol.
It's a slippery slope that I rather not step down into.

However, I am also quite willing to consider other options...
I'll even offer another one myself:

Replace:

with:
  The relationship between an AttributeDescription with
  one or more options with an AttributeDescription with
  the same or related attribute type and a subset of the
  same options is not defined in general.  Such semantics
  are defined on an option by option basis.

and update ;binary (and ;lang-*) as approrpiate.

Another approach would be to do both.  That is, make the
replacement, remove ;binary to a separate document (an
extension).  This would keep the "redesign" out of LDAPbis.

Kurt