X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 08 May 2002 16:03:48 -0700
To: ietf-ldapbis@OpenLDAP.org
From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: ;binary a/b design teams' summary / recommendation review
Sender: owner-ietf-ldapbis@OpenLDAP.org
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:ietf-ldapbis-request@OpenLDAP.org?body=help>
List-Unsubscribe: <mailto:ietf-ldapbis-request@OpenLDAP.org?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