[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: String Encodings - was RE: Applicability Stmt (AS) rescinding "IESG Note" and defining "LDAPv3"
Bruce said
> 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 ...
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
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@salford.ac.uk
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
***************************************************