[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ;binary design teams



Title: RE: ;binary design teams

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:JIMSE@novell.com]
> Sent: Monday, April 22, 2002 8:43 PM
> To: ietf-ldapbis@OpenLDAP.org; Kurt@OpenLDAP.org
> 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" <Kurt@OpenLDAP.org> 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
>
>
>