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

Re: o and c or dc?

> Hello i'm also developing a LDAP sys, and i'm using dc=org.country.XX.
> I'm not breaking de domain component, is this completly incorrect?

"dc" stands for "domain component"; for instance,
in www.openldap.org, domain components are "www",
"openldap" and "org".  If you use "dc=www.openldap.org"
you're violating at least the semantics of "dc".
There are more appropriate attributes for a FQDN,
e.g. "associatedDomain", which is present in the
"domainRelatedObject" auxiliary objectClass (though
it mightnot be wise to use an attribute from an
auxiliary class for naming purposes, e.g. in a DN;
for this purpose, RFC 2247 describes the use of "dc"
in "domain" as structural objectClass, and "dcObject"
as auxiliary objectClass for entries that need to
have another structural objectClass while preserving
the "dc" naming).

>
> I'm doing that way, because is more simple for normal user to understand
> is login.
>
> Exists same RFC that indicates the correct form to make a LDAP draw?

RFC 2247 point 4:

4. Attribute Type Definition

   The DC (short for domainComponent) attribute type is defined as
   follows:

    ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
     SUBSTR caseIgnoreIA5SubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

   The value of this attribute is a string holding one component of a
   domain name.  The encoding of IA5String for use in LDAP is simply the
   characters of the string itself.  The equality matching rule is case
   insensitive, as is today's DNS.

Note the "one component" definition ...

p.

>
> Thanks
>
> Paulo Calçada
>
>> On Mon, Jan 12, 2004 at 03:35:43PM -0400, Ace Suares wrote:
>>
>>> > The main difference is in how easy it would be for a user to find
>>> your directory when they want it.
>>>
>>> Yes, if you are trying to implement something under ONE domain.
>>
>> Not at all - it is quite possible to have white-pages service across
>> any number of domains. In the PARADISE X.500 network, we built user
>> interfaces that would happily go and search for things like:
>>
>> 	smith, university, europe
>>
>> That would look for anyone called Smith (or Smithers or Smithson
>> or...) in any organisation calling itself a university in any country
>> that declared itself to be in Europe. In practice this is *not* a
>> sensible search and you don't want people doing it as it soaks up
>> resources at a frantic rate, but it *was* possible. If the development
>> of LDAP is taken just a bit further and someone deploys a top-level
>> server then it would be possible again.
>>
>>> What do you suggest if you implement something with many domains,
>>> like a  virtual domain hosting ISP ?
>>
>> It all depends on what sort of searches you want to support. I have
>> built a mail system based around LDAP that does exactly what you
>> describe, and I chose to place the 'customer domains' under an OU
>> beneath my own organisation entry. In this case, the organisation
>> entry was in dc= format, but it could equally well have been in o=, c=
>> form. The critical consideration was that my mail admin tool needs
>> complete authority over the subtree that it uses to define mail
>> routing. White pages lookups are still possible but are very much a
>> secondary
>> requirement (if I were going to advertise a white-pages service I
>> might well offer to alias each customer's data into the 'proper' place
>> in the DIT)
>>
>> As a concrete example, suppose suares.nl wants to run a mail service
>> for some well-known characters. It obviously has absolute rights to
>> use dc=suares,dc=nl and anything underneath, so I would suggest
>> starting with ou=mailsystem,dc=suares,dc=nl as the root of the system.
>> Under that node, you could follow the Lachman-LASER scheme or you
>> could define your own schema. I defined my own as I had some specific
>> requirements that did not quite fit with Lachman-LASER. I chose to put
>> my customer domains in a subtree called ou=domains,dc=..... and each
>> domain has its own data under
>>  associatedDomain=<customer DNS name>,ou=domains,dc=....
>> (This should make delegated management possible later if I need it,
>> using ACLs). Each individual mail user gets an entry at the next level
>> down, containing routing data, username, password (for IMAP) etc. Thus
>> we would see:
>>
>> 	Main entry for the firytales.org customer:
>> 	associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>>
>> 	Some client mail-users:
>> 	cn=Snow
>> White,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>> cn=Grumpy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>> cn=Snoozy,associatedDomain=fairytales.org,ou=mailsystem,dc=suares,dc=nl
>>
>> White pages lookups across the whole customer set are possible using a
>> search base of ou=mailsystem,dc=suares,dc=nl but you may prefer to
>> alias the entries into things like:
>>
>> 	cn=Grumpy,dc=fairytales,dc=org
>>
>> 	or
>>
>> 	cn=Grumpy,o=Seven Dwarves,c=Fairyland
>>
>> The problem then is that current user-interfaces would have trouble
>> searching across all customers at once. This might well be considered
>> an advantage :-)
>>
>> Andrew
>> --
>> -----------------------------------------------------------------------
>> |                 From Andrew Findlay, Skills 1st Ltd
>> | | Consultant in large-scale systems, networks, and directory
>> services | |     http://www.skills-1st.co.uk/                +44 1628
>> 782565     |
>> -----------------------------------------------------------------------


-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it