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

Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
Subject: Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
From: David Chadwick <d.w.chadwick@salford.ac.uk>
Date: Sat, 02 Mar 2002 22:22:37 +0000
Cc: Jim Sermersheim <JIMSE@novell.com>, ietf-ldapbis@OpenLDAP.org
Organization: University of Salford
References: <5.1.0.14.0.20020301114439.01710098@127.0.0.1>


"Kurt D. Zeilenga" wrote:
> 
> At 11:31 AM 2002-03-01, Jim Sermersheim wrote:
> >Let's try this one:
> >
> >"4.1.5.x. Binary Transfer Option
> >
> >If the "binary" option is present in an AttributeDescription, it
> >specifies that data within the AttributeValue(s) of the attribute be
> >transferred in protocol as BER encoded data according to the ASN.1 data
> >type corresponding to the attribute's LDAP syntax. The LDAP syntax is
> >indicated by the "SYNTAX" part of the AttributeTypeDescription.
> 
> I think we need to clarify that an ;binary in an AttributeDescription
> list indicates a request for binary transfer but ;binary in an
> AttributeDescription associated with an AttributeValue(s) or
> AssertionValue(s) indicates that the AttributeValue(s) or
> AssertionValue(s) contain a BER encoding of the value instead
> of the "native" string encoding of the value.
> 

Agreed.

> Some food for thought:
> 
>   If the "binary" option is present in an AttributeDescription
>   associated with AttributeValue(s) or AssertionValue(s), the
>   option indicates these AttributeValue(s) or Assertion(s) contain
>   a BER encoding, not the "native" string encoding, of the value.
> 
>   If the "binary" option is present in an AttributeDescription
>   in an AttributeDescriptionList, it signifies a request for
>   the return of the associated attribute (and its subtypes) using
>   binary transfer.
> 
>   The attribute associated with an AttributeDescription containing
>   the binary option is that which has the AttributeDescription of
>   the same attribute type and all options excepting the binary
>   option.
> 

I agree with all of the above

David
>   ...
> 
> >The presence or absence of the "binary" option only affects the
> >transfer of attribute values in protocol; servers store any particular
> >attribute in a server-defined format. If a client requests that a server
> >return an attribute in the binary format, but the server cannot generate
> >that format, the server MUST treat the attribute type as unrecognized.
> >Similarly, clients MUST NOT expect servers to return an attribute in
> >binary format if the client requested that attribute by name without the
> >"binary" option.
> >
> >This option is intended to be used with attributes whose syntax is a
> >complex ASN.1 data type, but may be associated with any attribute whose
> >ASN.1 type is known."
> >
> >(Note that AttributeValue is defined as an OCTET STRING containing some
> >encoded data per the syntax and possibly further specified by a transfer
> >option)
> 
> Note that the AttributeValue and AssertionValue are OCTET STRINGs
> which contain an encoding of the value per its syntax.  ;binary
> indicates the BER encoding is used.  Other transfer options indicate
> other encodings.  The lack of a transfer option indicates the
> "native" string encoding is used.
> 
> >Jim
> >
> >>>> David Chadwick <d.w.chadwick@salford.ac.uk> 02/24/02 04:17PM >>>
> >Jim
> >
> >I think the new text for attribute descriptions is very good. Much
> >better than before, especially the description of subtyping. However,
> >the subsection on Binary Option (4.1.5.1) could still do with some
> >improvement I feel. Firstly, the section is not as clear as recent
> >email
> >we have had on the list, explaining that the attribute value, whatever
> >it is, is treated (or turned into) as an octet string containing BER,
> >and then a TL octet wrapper is placed around it.
> >
> >Secondly, the section talks about overriding the native encoding and
> >sending it as BER instead. But then your example uses certificates,
> >that
> >are native BER encoded. So what overriding is there to take place. It
> >would seem like none, and therefore the effect of ;binary is null. In
> >other words the section does not clearly indicate to me what the
> >difference would be in transferring a certificate without ;binary and
> >one with i.e. certificate;binary.  This is unfortunate and confusing
> >to
> >the reader. I suggest you use an example that is not a certificate,
> >but
> >is a simple string. You might then also add text to say what the
> >effect
> >of ;binary is on a value that is already BER encoded.
> >
> >I find this sentence particular confusing
> >
> >"Instead the attribute is to be transferred as
> >   a binary value encoded using the Basic Encoding Rules [X.690]."
> >
> >The reason it is confusing is that all values in BER are binary. So if
> >the value is already BER what more needs to be done to it? It would
> >seem
> >nothing.
> >
> >Perhaps the sentence might read better as
> >
> >"Instead the attribute value is transferred as an ASN.1
> >OctetStringType,
> >where the embedded octet string value is itself a BER encoded value"
> >
> >
> >The second sentence
> >"The
> >   syntax of the binary value is an ASN.1 data type definition, which
> >is
> >   referenced by the "SYNTAX" part of the attribute type definition."
> >
> >also has some errors in it, and could then be changed to
> >
> >"The syntax of the BER encoded value is an ASN.1 data type, which
> >must conform to the "SYNTAX" part of the AttributeTypeDescription."
> >
> >Is that any better?
> >
> >David
> >
> >Jim Sermersheim wrote:
> >>
> >> All,
> >>
> >> This revision contains the changes recommended by the attribute
> >options
> >> engineering team. Please review section 4.1.5 carefully.
> >>
> >> Other changes are listed in section B.7
> >>
> >> Jim
> >>
> >> >>> <Internet-Drafts@ietf.org> 01/31/02 05:00AM >>>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >> This draft is a work item of the LDAP (v3) Revision Working Group of
> >> the IETF.
> >>
> >>         Title           : Lightweight Directory Access Protocol (v3)
> >>         Author(s)       : J. Sermersheim
> >>         Filename        : draft-ietf-ldapbis-protocol-06.txt
> >>         Pages           : 56
> >>         Date            : 30-Jan-02
> >>
> >> The protocol described in this document is designed to provide
> >access
> >> to directories supporting the [X.500] models, while not incurring
> >the
> >> resource requirements of the X.500 Directory Access Protocol (DAP).
> >> This protocol is specifically targeted at management applications
> >and
> >> browser applications that provide read/write interactive access to
> >> directories. When used with a directory supporting the X.500
> >> protocols, it is intended to be a complement to the X.500 DAP.
> >>
> >> A URL for this Internet-Draft is:
> >>
> >http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-06.txt
> >
> >>
> >> To remove yourself from the IETF Announcement list, send a message
> >to
> >> ietf-announce-request with the word unsubscribe in the body of the
> >> message.
> >>
> >> Internet-Drafts are also available by anonymous FTP. Login with the
> >> username
> >> "anonymous" and a password of your e-mail address. After logging in,
> >> type "cd internet-drafts" and then
> >>         "get draft-ietf-ldapbis-protocol-06.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >> Internet-Drafts can also be obtained by e-mail.
> >>
> >> Send a message to:
> >>         mailserv@ietf.org.
> >> In the body type:
> >>         "FILE /internet-drafts/draft-ietf-ldapbis-protocol-06.txt".
> >>
> >> NOTE:   The mail server at ietf.org can return the document in
> >>         MIME-encoded form by using the "mpack" utility.  To use this
> >>         feature, insert the command "ENCODING mime" before the
> >"FILE"
> >>         command.  To decode the response(s), you will need "munpack"
> >or
> >>         a MIME-compliant mail reader.  Different MIME-compliant mail
> >> readers
> >>         exhibit different behavior, especially when dealing with
> >>         "multipart" MIME messages (i.e. documents which have been
> >split
> >>         up into multiple messages), so check your local
> >documentation
> >> on
> >>         how to manipulate these messages.
> >>
> >>
> >> Below is the data which will enable a MIME compliant mail reader
> >> implementation to automatically retrieve the ASCII version of the
> >> Internet-Draft.
> >
> >--
> >*****************************************************************
> >
> >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
> >
> >*****************************************************************

-- 
*****************************************************************

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

References:
- Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
  - From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>

Prev by Date: Re: More on ;binary
Next by Date: Re: ;binary and *
Index(es):
- Chronological
- Thread