[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
refer-00.txt - separate attributes or options or object classes
Steven said
>
> I'd prefer to use separate attributes instead of separate options to
> convey the semantics but that's not critical.
>
In fact the two can be the same to my mind. An option is an
attribute subclass, and by defining an OID for the option/subclass,
you achieve the same thing. (Similar to name and commonName)
> > > 2.1 The refer attribute
> > > The refer attribute can be further specified by the use
> > of options as
> > > defined in section 4.1.5 of [RFC2251]. This document defines
> > > five options and their use. Future documents might defined
> > other options.
In fact it defines six. If just forgot to describe refer;other at the start
of the ID
> >
> > Is an option required? If not, what is the semantics of an
> > optionless refer attribute?
Good question. In fact, I would say that the attribute should always
have an option defined. (just as we never use the name attribute on
its own, but always a subtype of it)
However, there is one problem with the option/subtype route, and
that is the DSAOperation vs. DistributedOperation question. I
believe that some (sup, me) are for local DSAOperation use, whilst
others (cross, sub, other) are domain replicable i.e. for
DistributedOperation use. This is why in my 1998 ID I had TWO
attribute types, named sharedRef and privateRef. I still think this
requirement exists.
David
***************************************************
David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351 Fax +44 161 745 8169
Mobile +44 790 167 0359
Email D.W.Chadwick@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 MLJ9-DU5T-HV8J
***************************************************