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

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