[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(Fwd) Fwd and comments on IETF "Use of Language Codes in LDAP"
Steve
You asked for a comparison of LDAP language codes and X.500 contexts.
Kevin O'Shea provided an excellent comparison to the X.500 group over
a year ago. Here it is.
There is also one further item that I would like to add. X.500
has the concept of attribute hierarchies, which is quite distinct
from contexts, whereas in LDAP, the attribute description and
;options mechanism caters for both concepts.
David
------- Forwarded Message Follows -------
Date: Tue, 19 Nov 96 15:34:57 EST
From: "O'Shea, Kevin" <kevin.o'shea@pscinc.ca>
To: OSIdirectory@az05.bull.com
Subject: Fwd and comments on IETF "Use of Language Codes in LDAP"
Ella forwarded the notice below to me about an Internet draft dealing with the
inclusion of language codes in LDAP to tag attribute values with the natural
language that pertains. Guess what? It's contexts!
After my initial read, I offer my observations here to those interested in
starting a debate about the best way to approach this to prevent too much
divergence. After all, LDAP should be a proper subset of DAP, no?
In the following, I point out the similarities and difference between the LDAP
solution and the Contexts solution now in X.500.
In LDAP, an AttributeDescription is used to specify the type and options that go
along with an attribute value. The internet draft is defining an option for
specifying the language of the value within the AttributeDescription.
Syntactically, the language gets rolled into the type rather than the value as
X.500 does with context lists, and it causes some different interpretations.
For example, matching is allowed to fail if the language is over-specified
because this is interpreted as a different attribute type.
The LDAP solution deals only with language and is not generalized to other
contexts. The language codes used (context values in X.500 lingo) seem to be
the same as the X.500 printable-string locale context values, but I'll have to
check out the source (RFC 1766) to be sure.
LDAP introduces the preferredLanguage service control. This is a bit like
the X.500 operationContext service control, plus the contextSelection in
EntryInformationSelection, all rolled into one. Much the same
interpretation, without the full power of all those cascading defaults we
have in X.500. It could be made parallel to operationContext. LDAP does
not apply the preferredLanguage control to search filters or compare
operations (X.500 does). Both use it for read, and entry information
selection.
LDAP specifies that a single attribute value can have only one language tag.
X.500 allows multiple values for a given context, allowing a value to be tagged
as appropriate to several languages at once. LDAP does allow the same attribute
value to appear twice in an entry as long as there are different language tags;
I suppose in protocol it amounts to the same thing, just less compact.
LDAP allows for substring matches on the string language value (e.g., "en"
matches "en-US"), at least in one direction. There may be some inconsistency in
this, for some of the examples seem to imply full string matches only, but I
think I need to read it a few more times to be sure.
One significant difference on matching is that a specified language will not
match with a stored value that has no language tag. This is unlike X.500 where
a missing context in a stored value implies it will match under any context (if
it doesn't say, then sure it's French or whatever"). Of course, LDAP does not
have the fallback flag.
The LDAP draft explicitly excludes language codes in RDNs and DNs. X.500 goes
through contortions to allow them, since we decided that names (particularly
organizational names) are precisely one of the useful places for contexts.
LDAP and X.500 allow contexts in search filters. Both allow a search filter
without language tags to match stored values with them. (But LDAP refuses the
reverse).
LDAP says that a Modify-delete will only work if the value specified includes
the stored language code tags too; X.500 is more lenient.
LDAP does not have a concept like X.500 Context Use rules. The internet draft
states that language codes must be supported for all attribute types whose
syntax is DirectoryString. It says servers may allow language codes with other
types. But the flexibility of Context Use for controlling tags in a sub-schema
is not there.
LDAP adds a new twist. It allows the preferredLanguage service control to
govern diagnostic messages returned from the server. An interesting concept -
if your error codes are more exciting than OIDs.
Anyway, that is a few observations. Bottom line: the concept is a subset of
Contexts, for sure, but there are a few variations that should at least be
brought forward. It would be nice for vendors/users if the mapping between LDAP
v3 and X.500:1997 were straightforward.
Does anyone have experience/protocol/advice for approaching the authors of
internet drafts? I'd be willing to enter into discussions.
Kevin O'Shea
_
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.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
***************************************************