Re: FWD: ;binary a/b design teams' summary / recommendation review

[Steve Hanna <steve.hanna@sun.com>]

Russ Housley forwarded the email below (announcing the
LDAPBIS group's intent to remove the ;binary option) to
the PKIX mailing list, suggesting follow-ups to this list.

Doesn't removing support for the ;binary option break
backward compatibility for LDAP clients that use the
;binary option to store and retrieve certificates and CRLs?

Since RFC 2256 required the use of ;binary to store and
retrieve certificates and CRLs, I would hope that you
would require servers to support older clients for backward
compatibility. In fact, newer clients will also need to use
the ;binary option when storing and retrieving certificates
and CRLs in case they are talking to an older server. I guess
you'd better document that, too.

Are you sure this is simplifying things for you?

Steve Hanna
Sun Microsystems, Inc.

"Housley, Russ" wrote:
> 
> Please take any discussion of this topic to the LDAPbis mail list.  I post
> it here to ensure that everyone who cares about this issue is aware it.
> 
> Russ
> 
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Wednesday, May 08, 2002 7:04 PM
> To: ietf-ldapbis@OpenLDAP.org
> Subject: ;binary a/b design teams' summary / recommendation review
> 
> 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