Subject: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"

From: "Steven Legg" <[email-masked]>
Date: Mon, 3 Jul 2000 11:19:47 +1000

David,

> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: Friday, 30 June 2000 3:38
> To: [email-masked]; [email-masked]
> Cc: RLBob Morgan
> Subject: Re: Applicability Stmt (AS) rescinding "IESG Note" 
> and defining
> "LDAPv3"

[snip]

> RFC2587 does not describe in detail the matching rules that 
> should be supported by LDAP servers, nor does it describe 
> how attribute value assertions for each matching rule 
> should be encoded in filter items (in fact these AVA 
> encodings are not currently described anywhere).

It's a shame the LDAP string encodings for attribute values weren't defined
by some algorithmic relationship to the ASN.1 type of the syntax, much
like the way ASN.1 value notation is related to the type. It wouldn't
then be necessary to define a string encoding for each new attribute
value syntax or assertion value syntax imported from X.500, X.509, etc.
The required string encoding would fall out naturally from the relevant
ASN.1 type.

It's never too late to start though.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 05 Jul 2000 11:02:22 -0700

>It's never too late to start though.

You could request ;binary transfer for all attributes...  :-)

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 05 Jul 2000 12:42:04 -0700

>You could request ;binary transfer for all attributes...  :-)

Or one could stop defining these new attribute syntaxes, and make do with 
strings...

Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 Jul 2000 07:42:58 -0700

At 12:42 PM 7/5/00 -0700, Bruce Greenblatt wrote:
>Or one could stop defining these new attribute syntaxes, and make do with strings...

And treat attributes as blobs, sure, why not?

---

From: Bruce Greenblatt <[email-masked]>
Date: Thu, 06 Jul 2000 08:30:11 -0700

strings...
>And treat attributes as blobs, sure, why not?

Kurt,

That's not what I meant at all.  Sorry for the confusion.  Instead of
defining a new syntax, make use of the existing syntaxes.  Here's a simple
example for the telephone number attribute.  I could define a new syntax like:

TelephoneNumber  ::= SEQUENCE {
              countryCode   [0]    DirectoryString,
              areaCode      [1]    DirectoryString,
              localNumber   [2]    DirectoryString }

for use in attribute types that need telephone numbers, or I could just
directly use the DirectoryString syntax for these, and indicate that they
obey the following BNF:

telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" whsp localNumber
...

IMHO, this is a better approach.  I see no benefit in defining that exact
structure of the data at the Presentation Layer.  As far as I've seen, even
when new syntaxes are defined, additional code must be written to interpret
and validate the attribute value anyway.  So, to me, it isn't clear exactly
what purpose they serve.  So, use the existing ASN.1 syntaxes, and define
the BNF as is done in clause 6 of RFC 2256...  This has the added benefit
of making the protocol easier to visually interpret by those of us that
have to look directly at it...

Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 9 Jul 2000 12:39:41 +0100

> It's a shame the LDAP string encodings for attribute values weren't
> defined by some algorithmic relationship to the ASN.1 type of the
> syntax, much like the way ASN.1 value notation is related to the type.
> It wouldn't then be necessary to define a string encoding for each new
> attribute value syntax or assertion value syntax imported from X.500,
> X.509, etc. The required string encoding would fall out naturally from
> the relevant ASN.1 type.

How right you are. I have noticed this when writing the latest 
schema ID for PKIX. 

> It's never too late to start though.

I could really do with a BNF wiz kid to help me do this on the PKIX 
schema. Are you such a person?

David

> Steven

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

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
Email [email-masked]
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
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

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

---

From: "David Chadwick" <[email-masked]>
Date: Sun, 9 Jul 2000 12:39:42 +0100

Bruce said

> defining a new syntax, make use of the existing syntaxes.  Here's a
> simple example for the telephone number attribute.  I could define a
> new syntax like:
> 
> for use in attribute types that need telephone numbers, or I could
> just directly use the DirectoryString syntax for these, and indicate
> that they obey the following BNF:
> 
> telephoneNumber = countryCode whsp "$" whsp areaCode whsp "$" whsp
> localNumber ...

I think you will find that the approaches are identical i.e. if we were 
to create an LDAP syntax of the ASN.1 telephone number above 
we would end up with exactly the same string value that you did. 
The difference comes in the backend server. An LDAP one will 
store the LDAP string as the attribute value whereas an X.500 
based one will store the ASN.1 value. An interesting point comes 
when we define the matching rules for this new telephone number. 
Will we let a user present just an area code, or just a local number 
or all three components, and what will be the syntax for the 
asserted value?

David

David Chadwick

---

From: Bruce Greenblatt <[email-masked]>
Date: Sun, 09 Jul 2000 13:25:24 -0700

>I think you will find that the approaches are identical i.e. if we were
... [snip]

I think that is the point that I'm trying to make...  There is no reason
(that I can see) to define new atttribute syntaxes when you can use the
existing ones.  It is not always easy or possible to extend the syntaxes
that are available on a directory server...Bruce

==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
New Book on Internet Directories:
http://www.phptr.com/ptrbooks/ptr_0139744525.html

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 10 Jul 2000 12:23:24 +1000

Bruce,

> From: Bruce Greenblatt [mailto:[email-masked]]
> Sent: Friday, 7 July 2000 1:30
> To: Kurt D. Zeilenga
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: String Encodings - was RE: Applicability Stmt (AS)
> rescinding "IESG Note" and defining "LDAPv3"
>
>
> defined
> what purpose they serve.

There is a benefit to me. The build of the Adacel View500 directory is
highly automated around ASN.1 type definitions. To add a new attribute
syntax I only need to paste the ASN.1 type definition into an ASN.1
source text file, add a single line of C code to an array initializer,
and start a rebuild. The ASN.1 compiler and ASN.1 run-time environment take
care of everything else, which includes BER + DER encoding & decoding
(obviously), formatting functions for rendering attribute values in
human readable form (i.e. ASN.1 value notation), parsing routines to
read them back in again, hashing functions used in indexing, syntax
checking routines, and integrity maintenance for any embedded DNs.
The report generation and diagnostic tools automatically become capable
of accessing the components of an attribute value, so a directory
administrator could, for example, write a script for the data extraction
utility that printed out only the ".localNumber" component of your
TelephoneNumber syntax above.

If the new syntax is amenable to one of the three *FirstComponentMatch
matching rules (or any other implemented matching rule for that matter)
then I need only add one line to another array initializer to provide
matching and indexing of values of the syntax.
In the case of directoryStringFirstComponentMatch this gives me access
for free to a range of approximate matching (phonetic, keyword, synonym,
etc)
on the directory string first component.

Not bad productivity from a handful of lines of text.

However, I have to hand craft code to take care of the corresponding
LDAP string encodings. If the string encoding was algorithmically
related to the ASN.1 type then I could automate that stuff too!
If there is some internal structure to an attribute syntax that makes
it appropriate to define BNF to describe it then it is easier for me
if that internal structure is described by ASN.1, but I'll settle for
the BNF and ASN.1 being related in a predictable way.

> So, use the existing ASN.1
> syntaxes, and define

As an aside, a colleague of mine from Telstra recently put together an
LDAPv3 client that accepts as input the ASN.1 value notation for the
whole of an LDAP operation. It pushes readability to new levels.

A typical LDAP search request looks like this in value notation:

{
	messageID 1,
	protocolOp searchRequest:{
		baseObject "O=Deltawing, C=AU",
		scope wholeSubtree,
		derefAliases neverDerefAliases,
		sizeLimit 50,
		timeLimit 100,
		typesOnly FALSE,
		filter equalityMatch:{
			attributeDesc "CN",
			assertionValue "Andrew Sherman"
		},
		attributes { "S" }
	}
}

Imagine if this were the actual protocol message instead of BER :-) .

Strictly speaking the assertionValue field is an OCTET STRING, but our
ASN.1 run-time environment accepts octet strings containing only
printable characters as character strings for convenience.

Regards,
Steven

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 10 Jul 2000 13:41:04 +1000

David,

> Sent: Sunday, 9 July 2000 21:40
> To: [email-masked]; [email-masked]

I can help you on this. I've seen more than enough BNF and ASN.1 to be
useful. Let me know what you need done.

Cheers,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 Jul 2000 07:55:03 -0700

Regardless of whether you use a string representation or a BER/DER
representation of a value of a particular syntax, you need to define
an LDAPsyntaxes and appropriate matchingRules (and code that implements
them) if you want your server to check/match per the syntax.  Otherwise,
to the server, it's just a BLOB.

Kurt