>How we get all of these attrbutes implemented in DUAs is the real
>problem.
Its really not that much of an issue - when the attributes are not
distinguished. unless the application designer is using strange
attribute syntaxes, then its just a case of starting at the UI
"dod.internet.attributetype.1= fredstring" rather than
"localattribute= fredstring". All DUAs know the former, only onces
which know the schema know the latter fact.
Even this goes away under X.500 93 in which the schema is itself
described in the Directory! Any DUA can just then do a lookup!
x.500 93 is to the eixsting directory services what
MCImails pending switch to X.400 (88) is to
their corporate customers.
When the attributes syntax is unknown, then life is much harder, but
this is very rare. Most attributes are juststring of well established
character sets. this is why is so easy to map X.500 onto existing
databases (versus the private database which prototypes like QUipu build and
use).
When attributes are to be used for DIT construction (i.e. naming) then
they fall under a given naming architecture. The NADF has one, the
Internet has one, and there is always the default from CCITT. Internet
folks hate CCITT folks, and logically create their own for
their private community, which is logical, since they
like to talk and descirbe different things.
Now, this is the point at which the whole DN scam began. its again
a non issue. the Internet is a bunch of types who
wish to form a community. the communities dont tend
to interact much. Each defines and implements the a set for its needs.
the business community require data quality andservice qualitiy
assurances whichInternet types despise. So they form such as the NADF,
with competition goals, andattributes which describe quality of
service. its MTRs and Steve Kents *thesis* that this
civil naming portion (the shared DIT) is
suitable for the internet.
Steve Kents old argument was that the original naming architecture was
most suitable for the Internet types; in agreeing to the NADF reference
in the RFC 1422, I dont think he had considered the full domain
distribution model contemplated by the NADF; including its specifis
support for local attributes types to be defined by specific ADDMDs.
if one takes the UK and US PostalServices existing residency database,
then one can see how trivial it is to create 100,000,000 of DNs, based on the
naming attributes already coded and udner data quality
managementcontrol and now available on CD and on the Internet! (USPS
and NAT.GEOG sources) And should those be operated under an ADDMD, then
the naming within that tree might very well use private naming
architecture, already coded up.
The massive US miltary directory for DISN also has thesame propoerties.
The NADF is certainly a good thing - as it allows existing database to
be turned onto X.500 very fast indeed. rather than the traiditonal way
of Quipu (steve Kille) and pizarro (christian huitema et al) and
others.
The flexibility is the power, not the problem.