Subject: RE: ;binary design teams

From: Christopher Oliva <[email-masked]>
Date: Tue, 23 Apr 2002 14:29:49 -0400

AFAIK, Team B has not indicated that the native encoding automatically
becomes the binary encoding when the native encoding is otherwise not
specified. The key difference with certificates is that RFC 2252 mandates
that the binary encoding should be used to transfer certificate values. The
key question is if a syntax definition clearly states a specific encoding
must be used, does this also mean that the corresponding ";option" must be
used to request (and reply with) that encoding? An attribute syntax
definition that does not mandate a specific transfer encoding does not fall
into that category.

I suppose a second issue is this: can a native encoding be the ASN.1 BER
encoding and therefore not require the use of the ";binary" option ?
Personally, I think it can.

A third issue you have brought up is this: since you can define new native
encodings where an RFC previously did not define a native encoding for a
syntax, why can't this new native encoding be defined as a BER encoding of
the abstract ASN.1 syntax?

Chris.

> -----Original Message-----
> From: Jim Sermersheim [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 8:43 PM
> To: [email-masked]; [email-masked]
> Subject: Re: ;binary design teams
> 
> 
> I fall into team A except the case where a search attrs list requests
> all user attributes. I'd be glad to help with some text. I believe the
> case for allowing future LDAP-specific encodings for syntaxes missing
> them is stronger than the case for a syntax's LDAP-specific encoding
> being equal to its binary encoding when not specified.
> 
> Jim
> 
> >>> "Kurt D. Zeilenga" <[email-masked]> 04/19/02 09:58AM >>>
> Two design teams have been formed to offer replacement text
> for Section 4.1.5 of draft-ietf-ldapbis-protocol-07.txt to the
> WG.  A leader for each team has been chosen by the WG chairs from
> the team members.  This leader will serve as editor of the
> replacement text.  The design teams are expected to be
> short-lived (2-4 weeks).
> 
> Design Team A will offer replacement text consistent with the
> position that ;binary must be used to indicate the transfer
> of binary encoded values.
> 	Mark Smith (Lead), Steven Legg, David Chadwick
> 
> 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.
> 	David Chadwick (Lead), Chris Oliva, Tim Hahn
> 
> Additionally, chairs will participate in design team discussions.
> 
> Kurt, LDAPbis co-chair
> 
> 
>