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

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Mar 2002 12:49:37 -0700

<sigh>, I forgot to fix the bit about clients MUST NOT... Here's a
better one (I changes it to say "...MUST NOT expect servers to return an
attribute with the binary option..." rather than "...in the binary
format...". Hopefully this better reflects the intent.

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.

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 with
the binary option 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.

>>> "Jim Sermersheim" <[email-masked]> 03/01/02 12:31PM >>>
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.

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)

Jim

>>> David Chadwick <[email-masked]> 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
> 
> >>> <[email-masked]> 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:
>         [email-masked].
> 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: [email-masked] 
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

*****************************************************************

---

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 01 Mar 2002 14:39:08 -0700

I'll try to add these distinctions, but probably not until the next edit
(getting close here).

Jim

>>> "Timothy Hahn" <[email-masked]> 03/01/02 01:40PM >>>

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

Regards,
Tim Hahn

Internet: [email-masked] 
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"                               
                                                                  
                      <[email-masked]>         To:       "Jim
Sermersheim" <[email-masked]>                                         

                      Sent by:                    cc:      
<[email-masked]>, <[email-masked]>            
        
                      owner-ietf-ldapbis@O        Subject:  Re: I-D
ACTION:draft-ietf-ldapbis-protocol-06.txt                             
                      penLDAP.org                                      

                      03/01/2002 03:17 PM                              

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

  ...

server
generate
the
whose
some
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.

>Email: >[email-masked]

---

From: "Timothy Hahn" <[email-masked]>
Date: Sun, 3 Mar 2002 20:58:32 -0500

Steven,

Agreed.

Regards,
Tim Hahn

                                                                                                                                          
                      "Steven Legg"                                                                                                       
                      <steven.legg@adacel.        To:       Timothy Hahn/Endicott/IBM@IBMUS, <[email-masked]>                  
                      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:
> listing "in which operations" the effects of the "binary"
> option rather
> than against which ASN.1 construct.  The ASN.1 constructs
> from the protocol

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

Regards,
Steven

>                       <[email-masked]>         To:
> "Jim Sermersheim" <[email-masked]>
>
>                       Sent by:                    cc:
>                       owner-ietf-ldapbis@O        Subject:
> Re: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt
>
>                       penLDAP.org
>
>
>
>
>
>
>
>
>                       03/01/2002 03:17 PM
>
>
>
>
>
>
>
>
>
>
>
> >binary format if the client requested that attribute by name
> without the
> >"binary" option.
> >
> >(Note that AttributeValue is defined as an OCTET STRING
> containing some
> >encoded data per the syntax and possibly further specified
> by a transfer
> >option)
>

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 5 Mar 2002 18:27:52 +1100

Your wordnet is very brief. My (Oxford) dictionary starts with

1. Belonging to a person or thing by nature, innate, inherent, natural to.
2. Unadorned, simple, artless.
3. Of one's birth, where one was born; belonging to one by right of birth.
etc.

I guess you are using 'native' to mean 'natural'. Wordnet prefers
'original'. 'Normal' and 'usual' seem to characterise the LDAP encoding more
than original, natural, native. 'Homespun' would be too rustic.

Well, you've challenged me but I do not feel equal to the task. Does someone
have a thesaurus with some more suitable words?

(I've tried to think of a composer starting with 'R' but I can't un-ravel
the problem. You wrack your brains, I've Rachmaninov.)

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 5 March 2002 17:58
To: Ramsay, Ron
Cc: [email-masked]; [email-masked]
Subject: RE: I-D ACTION:draft-ietf-ldapbis-protocol-06.txt

At 10:11 PM 2002-03-04, Ramsay, Ron wrote:
>So let's just say there are two encodings. I am not saying the ASN.1 form
is
>'native', I am simply saying that, as the ASN.1 form came first, and, as
you
>say below, the string encoding is based on the ASN.1, one can hardly call
>the LDAP form 'native'.

Again, you imply that ASN.1 data type is an encoding.

Both LDAP encodings (string and binary) are based on the ASN.1
data type definitions, but the string representations were
not only the first encodings of the ASN.1 data type definitions
used in LDAP but are the encodings which originated in LDAP.
The binary transfer encodings were introduced subsequently
and are based on encodings used in DAP.

So, in the dictionary sense:
   native: adj 1: being such by origin.  [WordNet]

the term makes reasonable sense. 

> I would prefer a different adjective.

Such as?

Kurt