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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 08 May 2002 16:03:48 -0700

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

---

From: Mark Wahl <[email-masked]>
Date: Wed, 08 May 2002 21:42:33 -0500

> will gauge WG consensus and take appropriate actions.

Removal of this element and its capability would hinder further 
interoperability and should not be done.

The story that I remember being told about the early days of the IETF was 
that implementors of TCP/IP stacks came together for a bake-off, found a 
difference of understanding about how the checksumming algorithm was to be 
implemented, and then a choice of interpretation was made.  That choice 
was put into the revised spec and the implementors were then able to 
have their implementations interoperate.  

There have been LDAP interoperability tests for years now, which have found
issues and proposed changes to the spec based on what has been found to 
work in running code.  

Mark Wahl
Sun Microsystems Inc.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 09 May 2002 23:21:40 +0200

> issues and proposed changes to the spec based on what has been found to

Mark,

I'm sorry but I can't derive from the story above why ;binary should not
be removed.

Ciao, Michael.

---

From: Mark Wahl <[email-masked]>
Date: Thu, 09 May 2002 16:38:28 -0500

> I'm sorry but I can't derive from the story above why ;binary should not

Because we have interoperability today for userCertificate;binary and such,
which use ;binary.  If we need to clarify or restrict the scope of ;binary 
to increase interoperability even further that's OK, but removing it would 
decrease interoperability below where it is today.

Mark Wahl
Sun Microsystems Inc.

---

From: David Chadwick <[email-masked]>
Date: Tue, 14 May 2002 07:46:40 +0100

Mark

one of the reasons for removing ;binary is because there are
interoperability problems today. If it were not so, the topic would not
have caused such a large discussion

David

Mark Wahl wrote:
> Michael StrÃ¶der wrote:

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************