Subject: Re: interoperability of ;binary

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 03 Apr 2001 19:13:11 -0600

>>> "Kurt D. Zeilenga" <[email-masked]> 4/3/01 2:52:15 PM >>>
>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.

I agree that it has the smell of introducing complexities that were not there to begin with.

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

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

>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.

I like this suggestion. No, I love this suggestion. I'm taking it out for dinner and a movie tonight.

>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.

Doing this will require some care in that we don't 'cement' one transfer encoding in place for attribute values and assertion values in 2251bis.

Jim

---

From: "Timothy Hahn" <[email-masked]>
Date: Tue, 3 Apr 2001 21:14:56 -0400

Hi all,

As I indicated during the IETF meeting, I prefer that we classify 
attribute options as subtyping or non-subtyping.  All non-subtyping 
options that are present in an attribute description are ignored for 
purposes of subtyping determination/resolution.

I believe that removal of ;binary will do more harm than good at this 
point.  I would rather see it stay, with the definition that it is 
non-subtyping and implies that "bytes are bytes" when the attribute value 
is placed in protocol.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

"Jim Sermersheim" <[email-masked]>
Sent by: [email-masked]
04/03/2001 02:18 AM

        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        Re: interoperability of ;binary

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.

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: "Ramsay, Ron" <[email-masked]>
Date: Wed, 4 Apr 2001 14:17:04 +1000

Kurt,

RFC 2559 actually specifies the binary syntax for certificate.

This looks like the horns of a dilemma?

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, 4 April 2001 0:52
To: [email-masked]
Cc: [email-masked]
Subject: Re: interoperability of ;binary

At 10:07 AM 4/3/01 -0400, Mark C Smith wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>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).

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

-- Kurt