DEFAULT attributes with OBJECT-CLASS macro in X.521

Thread View: comp.protocols.iso

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Jacob Palme DSV Wed, 06 Jan 1993 10:01

#1395

Author: Jacob Palme DSV
Date: Wed, 06 Jan 1993 10:01

22 lines
1111 bytes

X.521 uses the OBJECT-CLASS macro, an example is:

person OBJECT-CLASS
        SUBCLASS OF top
        MUST CONTAIN {
                commonName,
                surname}
        MAY CONTAIN {
                description,
                seeAlso,
                telephoneNumber,
                userPassword}
        ::= {objectClass 6}

Question: Is it possible, with this representation, to represent
DEFAULT attributes, i.e. attributes which need not be included
in the object, but which always must have a value, and where
a default value, defined somewhere (where??) is used if the
are not explicitly stored in the object.

If not: How should the notation be extended to be able to
handle DEFAULTed attributes?

Re: DEFAULT attributes with OBJECT-CLASS macro in X.521

#1397

Author: Markus Kuhn
Date: Wed, 06 Jan 1993 14:37

51 lines
3064 bytes

jpalme@dsv.SU.SE (Jacob Palme DSV) writes:

>Question: Is it possible, with this representation, to represent
>DEFAULT attributes, i.e. attributes which need not be included
>in the object, but which always must have a value, and where
>a default value, defined somewhere (where??) is used if the
>are not explicitly stored in the object.

>If not: How should the notation be extended to be able to
>handle DEFAULTed attributes?

Shall the values of these defauls be considered by DSAs, e.g. should they
be transmitted in answers to querries and should the default values be
considered in searches? This would be a major change in the current X.500
functionality, that could often break interoperability (which DSA knows about
default values and which one does not?).

If the values shall not be considered by DSAs, than the default values are
something that need not at all be known to the whole X.500 system. Then
default values are application specific. If one application considers the
absence of a certain attribute as an indicator for a default value, than
no other application of different type has to do this. E.g. if a group 
communication user agent interpretes the absence of an attribute
notInterestedInCommercialJunkMail = Yes as nIICJM = No, than my standard
person lookup user agent should not be forced to display the same
interpretation, as the interpretation of the default value is application
specific.

If you extend the CLASS notation by a DEFAULT part, than you should take
care in your notation, that it becomes obvious to which type of application
this default value is relevant. If the classes you define are only subclasses
relevant to your application, than there would be no problem, if the defaults 
are indicated in the CLASS macro notation.

BTW: X.500(92) will allow you to use default attribute inheritance for subtrees.
This is already common practice in some existing applications (e.g. QUIPU),
but still has to be standardized. Attribute inheritance might in some
situations be an alternative for DEFAULT values ...

Just a few ideas ...

Markus

BTW: Is there a more recent version of the X.gc standard available online?
The Microsoft RTF file that I have found is version 8 and perhaps already quite
out of date.

-- 
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
--- Wer, wie, was? Wieso, weshalb, warum? Wer nichts fragt bleibt dumm. ---

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads