RE: ;binary design teams

["Jim Sermersheim" <JIMSE@novell.com>]

>>> Christopher Oliva <Chris.Oliva@entrust.com> 04/23/02 12:29PM >>>
>
>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.

If the syntax definition says that a value of this syntax is
transmitted as an xyz-encoded value, then the xyz encoding *is* the
LDAP-specific encoding. In this case, it would not be specified as
attr;xyz. If on the other hand, the definition says that the values are
transmitted as xyz-encoded values, and that an xyz attribute option is
used to signify this, then no LDAP-specific encoding exists. In this
second case, I prefer to require that ;xyz accompanies the attribute
type, and that one cannot send attr without a transfer encoding option
(unless an LDAP-specific encoding is defined).

I try to think of the lack of any transfer option as implying a
transfer option called "LDAP-specific".

>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.

Yes. As long as the syntax definition states that the value is to be
transferred that way, and doesn't mandate that ;binary be used.

>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?

It can. I think however, that something needs to be said about the
server advertising its capabilities. In other words, if syntax ABC is
defined with no LDAP-specific encoding, then at a later point, an
LDAP-specific encoding is defined for it, that a supportedFeature OID be
defined at the same time so that a client can know what the server is
capable of. In lieu of using supportedFeature, we may want to talk about
a more specialized way of advertising server support for different types
of attribute options (including the implied ;LDAP-specific option). I'm
not sure if this falls under LDAPBIS or not (it certainly has come up in
the past as an interoperability problem).

Jim

>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
> 
> 
>