🚀 go-pugleaf

I am just now trying to define som ASN.1 for group communication.

In group communication, there is a need to be able to refer
individually to the links defined by various heading fields
in an IPM-like heading. For example, primary-recipients creates
a sequence of links to recipients, and replied-to-IPM creates
a sequence of links to messages.

I want to be able to encode operations like "REMOVE the link
from message M to the recipient R". This can be done in two
ways. Either, I quote as arguments to the REMOVE operation
the IPM Identifier of the message M and the name of the recipient R,
or I quote as arguments to the REMOVE operation the IPM Identifier
of the message M plus the position of the reference to the
recipient R in the IPM heading.

A disadvantage with the first method is that it fails in cases
where the same recipient R occurs several times in the IPM-like
heading, since you do not know whether the intention is to
remove both, or only one of them, and if so, which of them.

Because of this, I intend to try the second method. What I need
is basically a way of identifying or naming the individual links
which occur in different heading fields in the IPM-like heading.

I am thus trying to define an ASN.1 which looks something like
this:

LinkName ::= SEQUENCE
        {
             ipmid-part,     IPMIdentifier, --- from X.420
             link-position   INTEGER (0<..MAX)
        }

Question one: Any more comments on the idea of identifying
links as part of IPM-like headings in this way. Is it OK,
or to hacked to be suitable?

Question two: Any comment on the choice between the two ways
of identifying the link to remove as discussed above?

Question three: Is it possible to define a fully defined
enumeration of the links in an IPM-like heading. There is
no problem with the elements of for example primary-recipients,
since this is defined as a SEQUENCE OF, i.e. with a defined
order.

There is however a problem with the heading fields, since
the IPM Heading is defined as a SET, i.e. no defined order
between the different heading fields.

One way of constructing an order would be to say that
number 1 is given to the originator field (if present),
the next numbers go to the elements of the authorizing-users
field (if any) and so on, ordering the heading fields by
their tag values in their definition in clause 7.2 of X.420.

Would this be an acceptable or suitable way to do.

Question four: A fourth alternative would be not to try to
use an IPM-like format at all for group communication
contributions. This would of course be neater, but then one
would lose the possibillity of co-working between IPM
messaging and group communication which I personally
find very desirable. What is your opinion on this?