home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / protocol / iso / 1472 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  2.9 KB
  1. Path: sparky!uunet!enterpoop.mit.edu!ira.uka.de!fauern!uni-erlangen.de!not-for-mail
  2. From: unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn)
  3. Newsgroups: comp.protocols.iso
  4. Subject: Re: DEFAULT attributes with OBJECT-CLASS macro in X.521
  5. Date: 6 Jan 1993 15:37:24 +0100
  6. Organization: Regionales Rechenzentrum Erlangen
  7. Message-ID: <1ieqr4EINNlf0@uni-erlangen.de>
  8. References: <229244*jpalme@su-kom.dsv.su.se>
  9. Reply-To: mskuhn@immd4.informatik.uni-erlangen.de
  10. NNTP-Posting-Host: cd4680fs.rrze.uni-erlangen.de
  11. Lines: 51
  12.  
  13. jpalme@dsv.SU.SE (Jacob Palme DSV) writes:
  14.  
  15. >Question: Is it possible, with this representation, to represent
  16. >DEFAULT attributes, i.e. attributes which need not be included
  17. >in the object, but which always must have a value, and where
  18. >a default value, defined somewhere (where??) is used if the
  19. >are not explicitly stored in the object.
  20.  
  21. >If not: How should the notation be extended to be able to
  22. >handle DEFAULTed attributes?
  23.  
  24. Shall the values of these defauls be considered by DSAs, e.g. should they
  25. be transmitted in answers to querries and should the default values be
  26. considered in searches? This would be a major change in the current X.500
  27. functionality, that could often break interoperability (which DSA knows about
  28. default values and which one does not?).
  29.  
  30. If the values shall not be considered by DSAs, than the default values are
  31. something that need not at all be known to the whole X.500 system. Then
  32. default values are application specific. If one application considers the
  33. absence of a certain attribute as an indicator for a default value, than
  34. no other application of different type has to do this. E.g. if a group 
  35. communication user agent interpretes the absence of an attribute
  36. notInterestedInCommercialJunkMail = Yes as nIICJM = No, than my standard
  37. person lookup user agent should not be forced to display the same
  38. interpretation, as the interpretation of the default value is application
  39. specific.
  40.  
  41. If you extend the CLASS notation by a DEFAULT part, than you should take
  42. care in your notation, that it becomes obvious to which type of application
  43. this default value is relevant. If the classes you define are only subclasses
  44. relevant to your application, than there would be no problem, if the defaults 
  45. are indicated in the CLASS macro notation.
  46.  
  47. BTW: X.500(92) will allow you to use default attribute inheritance for subtrees.
  48. This is already common practice in some existing applications (e.g. QUIPU),
  49. but still has to be standardized. Attribute inheritance might in some
  50. situations be an alternative for DEFAULT values ...
  51.  
  52. Just a few ideas ...
  53.  
  54. Markus
  55.  
  56. BTW: Is there a more recent version of the X.gc standard available online?
  57. The Microsoft RTF file that I have found is version 8 and perhaps already quite
  58. out of date.
  59.  
  60. -- 
  61. Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
  62. Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
  63. --- Wer, wie, was? Wieso, weshalb, warum? Wer nichts fragt bleibt dumm. ---
  64.