Re: info on X.500

[Alan Wong <[e-mail]>]

Greetings, Vincent.


>> I try it here once more.
>
>I have a feeling that this works better. Let me have a shot at it.

To be fair. I did receive a reply in comp.protocols.iso, but it was already
to late to change this message (saying I didn't receive anything).
Well, never mind. It's not that important.

>>1: There already seems to exist an X.500 space. I can browse thru it
>>using one of the public-domain X.500 dua's. (e.g. pixie, wax, wdua,
>>..).
>
>Yes this is correct. This X.500 name space is set up during the X.500
>Directory Pilot project and nowadays DANTE tries to co-ordinate some of
>this as an operational service, at least for parts of Europe. That's why my
>reply :-)

It's great to see at least _somebody_ still cares about international norms.
(I hope X.500 doesn't end up the same way X.400 does).

Are there any other directory-service-protocols 'competing' with X.500?
(novell? banyan Street-talk, ...)?


>>I did notice there are quite a differences between certain parts of
>>the X.500 tree. Some countries (like Belgium) have very few
>>organisations, each with only 1 or 2 people in it, while others (like
>>Denmark) have a lot of them.
>
>A lot of thinks happened in the past, some country (or better
>organisations) have a real emphasis on the development of X.500 (or
>directories) and see the importance (like SURFnet, SWITCH, etc.) and others
>are not of almost not participating.

Is there a reason for that, or just 'bad PR'?


>This is more a political problem and
>not really technical. *Directories will not succeed without management
>back-up* because it is far more than setting up a DSA.

Inside belgacom, there is a kind of 'battle' between X.500 and banyan-vines
street-talk.

(Althou, as we use decdns now, I guess X.500 will eventually 'win'.

>        The only thing I have to say here is watch out with sizes! Some
>countries used so-called bulk load tools to do a bulk load data, especially
>some universities. Some of these parts are not maintained at all! Quantity
>does not say anything about the quality.

The difference between (eg.) Belgium and Denmark  does is striking.


>... The great goal for the future is
>on one hand technical; an infrastructure build on the real standard and on
>the other side organisational; having proper agreements in place and
>controlling this.

question: how does one 'inforce' a international standard? How do you
'punish' somebody that doesn't supply the 'quality of service' requested.
(I guess, if you talk of 'organisational agreements', a minimal quality of
service will be demanded. Or am I wrong?)


>>Is there already a way to 'register' one-self into the X.500 space?
>
>This is a bigger issue than you think. At this moment there is an ad hoc
>approach: as long as no one used the name you can use it. A proper solution
>would be a national authority who is responsible for the name space. Mind
>that some countries again are far ahead in this field and have proper
>authorities controlling the name space! How this is solved within Belgium
>you would have to ask Nils (cc-ed).

Great! I (personally) will 'order' the (c=be, o=belgacom) part of the DIT.
If belgacom wants to use that name, I'll make them pay! ;-)

(BTW: that already happened with internet-names under the .com hierarchie)


>>- c=be, st=west-vlaanderen, l=oostende
>
>There is a difference between a residential and an organigram (?) structure.

In what way?
I understand that (c=be, o=xxx) will usually be served by a DSA in that
organisation, but who 'serves' a locality?

>>I even found people, right under the 'world'-level. (?)
>
>There should not be any, can you tell me who?

I am typing this offline, so I can't check this right-now, but they appeat
to be the X.500 managers of the Countries.

>>Now, did the documentation I read oversimpify things, or are that only
>>'irregularities' in the X.500 space?
>
>I think X.500 allows you to do pretty much, however there are some
>guidelines specified in RFC 1617 to keep it in control.

Another rfc to read. ;-)

>>If the non-existance of a hierarchy is a fact, hao does one how about
>>the search such a 'database'?
>
>Clever user agents with good search algorithms like "de". (telnet
>nameflow.dante.net, login dua)

As far as I can see, 'de' is only based on the (country -> organisation)
hierarchie. (country - state - locality seems to be inpossible to search).

>...In the
>future there could be an alternative to country nodes or even different
>DITs as commercial organisations could stand up and provide these directory
>services.

I don't understand.
Do you mean other hierarchies than (country - organisations), more DSA's on
top of a 1 country (each 'serving' a number of organisations under the same
country-node), or more DITs, completly seperated from eachother?


>The most common  thing to do is to set up a server for an
>organisation and put "cn=myself" under it.

A organisation with only one person under it. Isn't that a bit 'overkill'?


>>3: How does X.500 handle the fact that an object can/should be at more
>>places in the X.500 space? (Can it?)
>
>Aliasing or naming links. A short p[aper written by David Chadwick was
>produced for the last NameFLOW meeting and is available on the web
><http://www.dante.net/np/multi.html>.

sigh. Another text to read. ;-)

>>4: How does X.500 handle the fact that object can 'move'? Is there a
>>mechanisme to find back an objects (say a person), after they have
>>moved to another location in the X.500 tree? (say she/he went to work
>>for another company, or moved to another town??)
>
>Yes, you could use an alias ....
>Now, there are no bi-directional pointers and you will need some kind of
>"search engine" to check correctness and this is virtually impossible. This
>is explained by Paul Barker in <http://www.dante.net/np/papers.html> X.500
>Index DSAs which could provide a solution to this problem.

This reminds me of www, were there also are 'links' from on place in a
document to another (part of a) document.

There you have the same problem.
Say, you have a document 'A' pointing to document 'B'.

No problem, as long as 'B' doesn't move. In that case, A must be notified,
and the link to 'B' must be modified.

I've heard somewhere that 'they' (whoever that may be) are working a method
to make www-links bidirectional. (to be expected at least some years from now).

>Hope this helps a bit,

It sure did!

Cheerio! Kr. Bonne.
home: [e-mail]
work: [e-mail]
      (c=be, a=rtt, p=rttipc, s=bonne, g=kristoff)