Subject: RE: ;binary option

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 10 May 2002 10:54:04 +1000

Chris,

Unless there is a typo in your text, you seem to be saying that ;binary was
ignored for certificates, at least for the BLITS tests. It then seems
strange that you would now require it?

Ron.

-----Original Message-----
From: Chris Harding [mailto:[email-masked]]
Sent: Thursday, 9 May 2002 19:15
To: [email-masked]; [email-masked]
Subject: ;binary option

Hi -

The two IETF ldapbis ;binary design teams have now reported, and it looks 
as though the conclusion may be to remove ;binary from the specification.

I've just looked through BLITS, and this does not mention the ;binary 
option. There are many tests that use certificates, but they all give the 
attiibute type as userCertificate, cACertificate, etc, rather than 
userCertificate;binary etc. So there would seem to be no impact on BLITS. 
Whether there is an impact on how far implementations can pass the BLITS 
tests may be another matter.

I don't personally see any interoperability issues, provided that it is 
clear that the requirement is always to use the ;binary encoding for 
certificates etc. (per section 6.5 of RFC 2252) and that RFC 1778 (LDAP 
v2), which defines a different encoding, is now officially dead. Kurt, this 
isn't completely clear from your mail - am I right that this is what is 
intended?

>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Version 5.1
>Date: Wed, 08 May 2002 16:03:48 -0700
>To: [email-masked]
>From: "Kurt D. Zeilenga" <[email-masked]>
>Subject: ;binary a/b design teams' summary / recommendation review
>Sender: [email-masked]
>Priority: non-urgent
>X-Loop: OpenLDAP
>Comment: ietf-ldapbis mailing list <http://www.OpenLDAP.org/lists/>
>List-Archive: <http://www.OpenLDAP.org/lists/ietf-ldapbis/>
>List-Help: <mailto:[email-masked]?body=help>
>List-Unsubscribe:
<mailto:[email-masked]?body=unsubscribe>
>
>Two design teams were formed to consider how to clarify the
>specification of the ;binary (and other) transfer option
>features in the LDAP "core" technical specification.
>   http://www.openldap.org/lists/ietf-ldapbis/200204/msg00073.html
>
>This message provides a brief summary of the teams discussions,
>a combined recommendation, and initiates a 2-week WG discussion
>period to determine whether the WG consensus supports adopting
>the teams' recommendation.  Both design teams are now disbanded.
>
>While each team mission was to produce alternative text, both
>teams worked together to ensure each understood the issues
>and to determine the areas of contention.  One key area was
>the semantics of all user attribute search requests. One camp
>(a cross section of both teams), basically, thought that a
>server should choose between returning either the native
>encoding (if defined and supported) and the binary (if supported)
>encoding.  One camp thought that a server should only return
>values in their native encoding (to avoid interoperability caused
>by a server choice).  After much debate, it was found that both
>approaches are problematic.  In short, the first approach is
>problematic in that imperatives required to ensure
>interoperability caused by the server choice would limit the
>general usefulness of all user attribute search requests.
>The second approach is problematic because it requires
>redefinition of all user attributes requests in a manner
>inconsistent with the existing technical specification.
>
>It was clear that the camps were deadlocked and that it
>would be difficult for either camp to garner WG consensus.
>
>Removal of the ;binary feature (and all mention of transfer
>options) was then discussed.  The teams concluded that,
>given the known interoperability problems with ;binary,
>limitations of the ;binary features, and the unsuitability
>of proposed revisions of its technical specification, the
>;binary feature (and all mention of transfer options)
>should be removed from the technical specification.
>
>The teams recognized that removal of the ;binary feature
>would raise some backwards compatibility issues and is an
>area which subsequent work may be appropriate to pursue.
>
>The WG is to consider the teams' proposal to remove ;binary
>feature (and all mention of transfer options).  A two-week
>comment period is hereby initiated on this proposal
>ending 24 May 2002.  Based upon your comments, the WG chairs
>will gauge WG consensus and take appropriate actions.
>
>-- LDAPbis WG chairs

Regards,

Chris
+++++

========================================================================
            Dr. Christopher J. Harding
   T H E    Executive Director for the Directory Interoperability Forum
  O P E N   Apex Plaza, Forbury Road, Reading RG1 1AX, UK
G R O U P  Mailto:[email-masked] Phone: +44 118 902 3018
            WWW: http://www.opengroup.org Mobile: +44 774 063 1520
========================================================================
The Open Group Conference
"Boundaryless Information Systems: The Role of Web Services"
Boston, Massachusetts 22-26 July 2002
http://www.opengroup.org/boston2002
========================================================================

---

From: Michael Ströder <[email-masked]>
Date: Fri, 10 May 2002 10:51:25 +0200

Ramsay, Ron wrote:
> ignored for certificates, at least for the BLITS tests.

And I'd like to add that the BLITS data did not work out of the 
box with at least some versions of OpenLDAP 2.0.x since OpenLDAP 
mandates (or mandated?) the use of ;binary. Kurt should know the 
details much better.

Ciao, Michael.

---

From: Chris Harding <[email-masked]>
Date: Fri, 10 May 2002 12:38:34 +0100

Hi -

At 10:51 10/05/2002 +0200, Michael Ströder wrote:
>And I'd like to add that the BLITS data did not work out of the box with 
>at least some versions of OpenLDAP 2.0.x since OpenLDAP mandates (or 
>mandated?) the use of ;binary. Kurt should know the details much better.
>
>Ciao, Michael.

BLITS testing is typically done manually, by typing information into 
clients. It may well be that testers have sometimes included the ;binary 
option even though the BLITS description does not explicitly call for it.

The BLITS server test data is contained in LDIF files. These use the "< 
file" LDIF construct to import the certificates, which are in DER or PEM 
form. However, I'm not sure that anyone has used this data exactly as 
supplied; typically, testers have to modify the supplied data in various 
ways in order to load it into their servers successfully.

Regards,

Chris
+++++