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

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



Tim,

Timothy Hahn wrote:
> Kurt,
> 
> In reading this, the thought occurs to me that we might be better off
> listing "in which operations" the effects of the "binary" 
> option rather
> than against which ASN.1 construct.  The ASN.1 constructs 
> from the protocol
> have a habit of showing up in other places later on ... and carrying
> forward the semantics of "binary" interpretation might not make sense
> there.
> 
> I would rather see statements such as: when "binary" shows up in
> "AttributeDescriptionList" on a "search" operation, it means ....

Better still if we say: when a transfer option (e.g. "binary")
shows up in "AttributeDescription" ...

Regards,
Steven

> 
> Regards,
> Tim Hahn
> 
> Internet: hahnt@us.ibm.com
> Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
> phone: 607.752.6388     tie-line: 8/852.6388
> fax: 607.752.3681
> 
> 
> 
>                                                               
>                                                               
>               
>                       "Kurt D. Zeilenga"                      
>                                                               
>               
>                       <Kurt@OpenLDAP.org>         To:       
> "Jim Sermersheim" <JIMSE@novell.com>                          
>                 
>                       Sent by:                    cc:       
> <d.w.chadwick@salford.ac.uk>, <ietf-ldapbis@OpenLDAP.org>     
>                 
>                       owner-ietf-ldapbis@O        Subject:  
> Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt             
>                 
>                       penLDAP.org                             
>                                                               
>               
>                                                               
>                                                               
>               
>                                                               
>                                                               
>               
>                       03/01/2002 03:17 PM                     
>                                                               
>               
>                                                               
>                                                               
>               
>                                                               
>                                                               
>               
> 
> 
> 
> 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.
> 
> 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.
> 
>   ...
> 
> >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-protoc
> ol-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
> >
> >*****************************************************************
> 
> 
> 
> 
> 
>