RE: ;binary Concensus?

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

I am starting to find myself in the third camp. This would involve removing
references to binary from teh core documents and creating an
(informational?) I-D to describe the ;binary optiion.

The effect on *-protocol-* (RFC 2251) would be to explain that
o Not all syntaxes have a displayable form and clients should use special
processing with attributes they don't recognise.

The ;binary I-D would explain that
o In the case where syntaxes allow an ASN.1 encoding, this encoding may be
requested with the ;binary transfer option;
o Servers need not support the ;binary option and should return an (unknown
attribute?) error if a client uses the option in a request and its use with
the attribute is not supported;
o If the server supports the option, and a client request specifies the
option on an attribute, the corresponding attribute in the response must
have the ;binary option and must be encoded in the ASN.1 encoding specified
for the syntax of the attribute;
o In the case a client requests the return of all attributes, a server
should not attach ;binary to any attributes returned - this may affect the
encoding choice for the attribute;
o If a client requests ;binary for an attribute that does not have an ASN.1
encoding defined, a server may generate a default ASN.1 encoding, ie wrap
the value as an octet string (deprecated - only included for compatibility
with RFC 2251).

Put me in Team C!

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Thursday, 11 April 2002 10:53
To: David Chadwick
Cc: LDAP BIS
Subject: Re: ;binary Concensus?


At 04:40 PM 2002-04-10, David Chadwick wrote:
>There has been a lot of discussions on the use of ;binary, and clearly
>two opposing view points. One camp think its use is unnecessary, the
>other think it should be mandatory.

While I would not myself describe the "camps" in this manner,
I do agree there is contention and that "camps" appear to be
forming.

>I dont know how rough concensus is measured by the IETF

It's up to the chair(s) to gauge consensus.  At this point,
I gauge the LDAPbis WG has not having consensus in regards
to either the general specification of ;binary in
draft-ietf-ldapbis-protocol-xx.txt nor with the specific use
of ;binary in draft-ietf-pkix-ldap-schema-02.txt.

My current approach for addressing this contention was to see
if the WG can reach consensus regarding the ;binary
specification language of draft-ietf-ldapbis-protocol-xx.txt
and then draft-ietf-pkix-ldap-schema-02.txt to be specified
in a manner consistent with draft-ietf-ldapbis-protocol-xx.txt.
It is, of course, important that the language used to clarify
draft-ietf-ldapbis-protocol-xx.txt preserve the demonstrated
interoperability for LDAPv3 certificate access.

What I would like to see is the those in each camp, operating
as a design camp, offer text which provides a clear and concise
specification of ;binary,  e.g. replacement text for Section
4.1.5 of draft-ietf-ldapbis-protocol-07.txt, for the WG to
consider.

Design Team A will offer replacement text consistent with the
position that ;binary must be used to indicate the transfer
of binary encoded values.

Design Team B will offer replacement text consistent with the
position that the use of ;binary is not necessary to indicate
the transfer of binary encoded values.

These teams are expected small (2-4 persons) and to be short
lived (2-4 weeks).

Those who wish to participate in this work should contact
Bob and I.  Please note which team you would like to be on.
 From the set of volunteers, Bob and I will appoint a team lead
who will edit the text produced by the team.  If the number of
volunteers is too many for the design team to be effective,
Bob and I (with advice from the team lead) will select which
volunteers will serve on the team.  The membership of each
list will be posted as soon as that determination has been
made.

Kurt