[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
Steven,
Agreed.
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
"Steven Legg"
<steven.legg@adacel. To: Timothy Hahn/Endicott/IBM@IBMUS, <ietf-ldapbis@OpenLDAP.org>
com.au> cc:
Sent by: Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
owner-ietf-ldapbis@O
penLDAP.org
03/03/2002 06:28 PM
Please respond to
steven.legg
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
> >
> >*****************************************************************
>
>
>
>
>
>