Re: Families of Entries

["Mark D. Anderson" <mda@discerning.com>]

Date sent:      	Tue, 22 Dec 1998 16:34:28 -0800

> >I have produced an example in the X.500 PDAM text.
> 
> That being the F510PDAMv12 document you posted a reference to before?

Yes correct. (although the terminoligy in that is slightly different)

> >Either the ID is not clear enough, or you have not read it properly.
> 
> Probably a bit of both, plus my own inexperience.
> I think I made the assumption that children were somehow
> not "real" entries because of the intro's reference to "subentries",

subentries are an X.500 term for administrative entries in the DIT - they are 
entries, but not normally visible to end users.

> and because the protocol section ("3. Protocol Support for Families")
> discusses just those family extensions exclusively. In never saw it stated
> explicitly that child entries are plain-old-entries also, and all the
> normal LDAP operations work on them just fine.
> 

Maybe I should add a sentence to the effect that AddEntry and 
ModifyEntry are normally used to add and modify child entries just 
like any other entry

> I can currently specify different values for a single attribute for
> "lang-en" and for "lang-fr". As such, language is currently a
> special-cased parameter ("child entry") in ldap.

Language tagging is an LDAP simplification of the X.500 concept of 
attribute value contexts. AVCs can be used to address many of the 
features of families as was pointed out at the IETF meeting (in fact 
Mark Wahl wants to continue to explore this some more), but as 
Erik Anderson pointed out to the list in an earlier message they 
cannot satisfy all the requirements.

> 
> >> Generally, properties are only attached to the whole complex object
> >> ("pref", "home", etc.)? That is where things get a little confusing --
> >> the semantics of the family hierarchy could either be containment or
> >> metadata.
> 
> >Containment I would say. Metadata is used to control the family 
> >hierarchy (as it is the rest of the DIT)
> 
> Sorry, I meant a different kind of "metadata" (properties). My point is
> that your single mechanism is used both for constituent parts ("city",
> "zip") and for properties ("home", "work"). I don't think this is
> necessarilly bad; I'm just trying to clarify.

These can all be regarded as properties of some bigger object e.g. 
a person - his zip code, his home telephone number etc, or 
properties can themselves be regarded as objects e.g. telephone 
numbers that themselves have properties e.g. location (home or 
work). So their is some metamorphis that can occur between 
attributes and objects. With object encapsulation a telephone 
number object is encapsulated inside a person object, so you only 
see the later.

David

> 
> -mda
> 
> 
> 


***************************************************

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
Entrust key validation string A7OX-K3QT-JPTU

***************************************************