Replacement? Supersedes? Something else?

[Ted Phelps]

At the Tickertape Workshop, we briefly touched on the topic of the
`Replacement' field and what should be done with it.  It is used to
signal that a notification contains transient information which may be
replaced by a subsequent notification with the same string value in
its `Replacement' field.  The disadvantage of this scheme is that the
first notification must indicate that it can be replaced.  The chief
advantage is that most messages cannot be replaced maliciously or
accidentally.

An alternative scheme, which I would like to see use a field named
`Supersedes', refers to the manditory `Message-Id' to indicate which
message is to be replaced.  This has the converse advantages and
disadvantages to the `Replacement' scheme: any message can be
superceded by anyone.  A user use this to repair tyops in already sent
messages (or bots could do this for them), but it would also allow a
malicious user to censor others.  However, if the tickertape application
were to provide some way of viewing superseded messages then I feel
these disadvantages are far less serious.

Note that each `Supersedes' notification would itself have a
`Message-Id' field which should be different from that of the message
it supersedes.  This has interesting (but unhelpful) ramifications:
bots need to maintain state in order to send updates and, more
annoyingly, a single message may be superseded multiple times (rather
than the third notification superseding the second).  It's not clear
to me how a tickertape should behave if this happens.

Because of these side-effects, I don't recommend that we use the
`Supersedes' scheme.  They do, however, suggest another scheme which I
quite like: we could merge the `Message-Id' and `Supersedes' fields.
Thus, if Message B arrives which has a Message-Id that matches a
message already received (Message A), then Message B replaces Message
A.  Like the `Supersedes' scheme, this has the advantage/disadvantage
that any message can be replaced, but without the unusual
side-effects.

I currently like this `Message-Id-only' scheme.  What do other people
think?

Cheers,
- -Ted

- --f8O9xwu03258.1001325606/dstc.edu.au--


------- End of Forwarded Message