Subject: Attribute Description Hierarchies and Policy Administration

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 04 Sep 2002 10:18:30 -0700

Steven Legg, Jim McMeeking, and I had a brief discussion regarding how
attribute descriptions hierarchies affect policy administration.
ldapbis-models was a bit unclear. We came up with the following
text for section 2.5.3 (replacing portions discussing subschema
and other policy administration) which should clarifying this.

  For the purpose of subschema administration of the entry, a required
  attribute requirement is fulfilled if the entry contains a value
  of an attribute description belonging to an attribute hierarchy if   
  the attribute type of that description is the same as the required
  attribute's type.  That is, a "MUST name" requirement is fulfilled
  by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' nor 
  by 'CN;x-tag-option'.  Likewise, an entry may contain a value of 
  an attribute description belonging to an attribute hierarchy if the
  attribute type of that description is either explicitly included
  in the definition of an object class to which the entry belongs or 
  allowed by the DIT content rule applicable to that entry permits   
  it.  That is, 'name' and 'name;x-tag-option' are allowed by "MAY 
  name" (or by "MUST name"), but 'CN' and 'CN;x-tag-option' are not        
  allowed by "MAY name" (nor by "MUST name").

  For the purposes of other policy administration, unless stated  
  otherwise in the specification of particular administrative model,  
  all of the attribute descriptions in an attribute hierarchy are  
  treated as distinct and unrelated descriptions.

Comments?

Kurt

---

From: David Chadwick <[email-masked]>
Date: Tue, 24 Sep 2002 21:26:43 +0100

Kurt

the proposed text does not sound OK to me for the following reason

An attribute subtype is a specialisation of an attribute supertype. For
example a mobile phone number is a subtype of a telephone number if
defined as such in the attribute type description. Likewise CN is a
subtype of name since it is defined as such. Consequently if an object
class specifies that a name must be present, this is fulfilled if
localityName, CN, surname or any other subtype of name is present in the
entry. If the admistrator wants to be more specific about what type of
name is present in an entry, then the object class definition should be
more specific. This seems to me like proper object oriented modelling

Regards

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
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: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 24 Sep 2002 14:58:38 -0700

>more specific. This seems to me like proper object oriented modelling

How do you reconcile the X.501 statements?
  For an entry to contain a value of an attribute type belonging to an attribute hierarchy,
  that type must be explicitly included either in the definition of an object class to which
  the entry belongs, or because the DIT content rule applicable to that entry permits it.

  All of the attribute types in an attribute hierarchy are treated as distinct and unrelated
  types for the purpose of administration of the entry and for user modification of entry
  content.

---

From: David Chadwick <[email-masked]>
Date: Mon, 30 Sep 2002 23:24:38 +0100

Kurt

So X.501 did not do a complete job of supporting attribute hierarchies
either:-) Seems like they are only supported in the search mode and not
in the update or admin modes. So to be compatible LDAP must do likewise.
Hence your original text stands. Sorry for objecting in the first place.

David