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

["Steven Legg" <steven.legg@adacel.com.au>]

Bruce,

> -----Original Message-----
> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
> Sent: Friday, 7 July 2000 1:30
> To: Kurt D. Zeilenga
> Cc: steven.legg@adacel.com.au; d.w.chadwick@salford.ac.uk;
> ietf-ldapext@netscape.com
> Subject: Re: String Encodings - was RE: Applicability Stmt (AS)
> rescinding "IESG Note" and defining "LDAPv3"
>
>
> At 07:42 AM 7/6/2000 -0700, Kurt D. Zeilenga wrote:
> >At 12:42 PM 7/5/00 -0700, Bruce Greenblatt wrote:
> >>At 11:02 AM 07/05/2000 -0700, Kurt D. Zeilenga wrote:
> >>>At 11:19 AM 7/3/00 +1000, Steven Legg wrote:
> >>>>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.
> >>>
> >>>You could request ;binary transfer for all attributes...  :-)
> >>
> >>Or one could stop defining these new attribute syntaxes,
> and make do with
> 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.

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

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

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