home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / protocol / iso / x400 / 737 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  3.1 KB
  1. Path: sparky!uunet!usc!news.service.uci.edu!ucivax!gateway
  2. From: jpalme@dsv.su.se (Jacob Palme DSV)
  3. Subject: Identification of fields in IPM-like headings
  4. Message-ID: <223783*jpalme@su-kom.dsv.su.se>
  5. Newsgroups: comp.protocols.iso.x400
  6. X400-Received: by /PRMD=SUNET/ADMD=_/C=SE/;
  7.     Relayed; 26 Dec 92 16:12:32+0100
  8. Approved: usenet@q2.ics.uci.edu
  9. Lines: 66
  10. Date: 26 Dec 92 15:18:51 GMT
  11.  
  12. I am just now trying to define som ASN.1 for group communication.
  13.  
  14. In group communication, there is a need to be able to refer
  15. individually to the links defined by various heading fields
  16. in an IPM-like heading. For example, primary-recipients creates
  17. a sequence of links to recipients, and replied-to-IPM creates
  18. a sequence of links to messages.
  19.  
  20. I want to be able to encode operations like "REMOVE the link
  21. from message M to the recipient R". This can be done in two
  22. ways. Either, I quote as arguments to the REMOVE operation
  23. the IPM Identifier of the message M and the name of the recipient R,
  24. or I quote as arguments to the REMOVE operation the IPM Identifier
  25. of the message M plus the position of the reference to the
  26. recipient R in the IPM heading.
  27.  
  28. A disadvantage with the first method is that it fails in cases
  29. where the same recipient R occurs several times in the IPM-like
  30. heading, since you do not know whether the intention is to
  31. remove both, or only one of them, and if so, which of them.
  32.  
  33. Because of this, I intend to try the second method. What I need
  34. is basically a way of identifying or naming the individual links
  35. which occur in different heading fields in the IPM-like heading.
  36.  
  37. I am thus trying to define an ASN.1 which looks something like
  38. this:
  39.  
  40. LinkName ::= SEQUENCE
  41.         {
  42.              ipmid-part,     IPMIdentifier, --- from X.420
  43.              link-position   INTEGER (0<..MAX)
  44.         }
  45.  
  46. Question one: Any more comments on the idea of identifying
  47. links as part of IPM-like headings in this way. Is it OK,
  48. or to hacked to be suitable?
  49.  
  50. Question two: Any comment on the choice between the two ways
  51. of identifying the link to remove as discussed above?
  52.  
  53. Question three: Is it possible to define a fully defined
  54. enumeration of the links in an IPM-like heading. There is
  55. no problem with the elements of for example primary-recipients,
  56. since this is defined as a SEQUENCE OF, i.e. with a defined
  57. order.
  58.  
  59. There is however a problem with the heading fields, since
  60. the IPM Heading is defined as a SET, i.e. no defined order
  61. between the different heading fields.
  62.  
  63. One way of constructing an order would be to say that
  64. number 1 is given to the originator field (if present),
  65. the next numbers go to the elements of the authorizing-users
  66. field (if any) and so on, ordering the heading fields by
  67. their tag values in their definition in clause 7.2 of X.420.
  68.  
  69. Would this be an acceptable or suitable way to do.
  70.  
  71. Question four: A fourth alternative would be not to try to
  72. use an IPM-like format at all for group communication
  73. contributions. This would of course be neater, but then one
  74. would lose the possibillity of co-working between IPM
  75. messaging and group communication which I personally
  76. find very desirable. What is your opinion on this?
  77.  
  78.