[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ;binary design teams
Jim
I can agree with all your comments
David
Jim Sermersheim wrote:
>
> >>> 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
> >
> >
> >
--
*****************************************************************
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: D.W.Chadwick@salford.ac.uk
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@salford.ac.uk
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard