[ticker-dev] Latest draft (was Re: Timeout attribute)

[Ian Lister]

An odd assortment:

Originally we had a discussion about whether the Replaces attribute should
refer to a specific previous message's Message-Id or whether it should be
a seperate identifier that a sequence of messages would share. We went for
the latter for a variety of reasons including supporting the ability to
track the sequence of messages even if a consumer doesn't receive them
all, and the supposed security benefits of being able to replace only
those messages which were tagged for replacement at production time. I
don't intend to revisit that decision, but I would like to set aside an
appropriate attribute name for any protocol or application for which the
Message-Id based methods is more appropriate (or which would like to use
both methods). The reason I would like to do this as part of the Ticker
spec process is that it may turn out that `Replaces' is the most
appropriate name for this, and it would be better to use a different name
for the Ticker-style method. Does anybody have any alternate name
suggestions for either?


At the risk of pushing my luck with the Timeout attribute I'd like to see
a recommendation in the draft that producers not specify arbitrary message
timeouts i.e. that unless there is a specific reason that the producer
doesn't believe a message will have validity after a certain time then a
Timeout should not be specified. This means that interactive clients would
default to having an unspecified timeout for each message.


The Distribution attribute is the only other one covered by the draft that
I am uncertain about. Sticker uses CLASSIFIED and UNCLASSIFIED (and now
`world'?) and DSTO filters traffic based on it, but I'm not aware of any
other client implementation or organisation using it. I'm not particularly
familiar with Sticker but IIRC it has a toggle control to choose between
the two values, which are hard-coded into the application rather than
configurable by the organisation (perhaps this has changed since I last
looked though). It seems to me that any implementation which provides the
functionality intended by the draft (that is, to allow organisations to
define distribution scopes and to allow scopes to be chosen on a user's
per-message basis rather than an administrator's per-channel basis) will
be significantly more complicated, probably introducing a pull-down menu
of known scopes. Currently, having the user select the correct channel can
be difficult enough - with issues about discovering channels, getting the
name exactly right (with associated case sensitivity nastiness), choosing
the correct channel for the correct message (not leaking onto an
inappropriate channel), etc - and it seems that introducing a scope menu
would have all the same issues (currently without the equivalent of
the presence protocol to discover scopes that other people are using) and
would be similarly important in getting messages to the right people.

Although breaking information up into discrete components is the
content-based way it seems to me that in this case breaking the
distribution apart from the topic are likely to add much more complication
for users than the benefits justify. It is possible that this may not turn
out to be the case, but my understanding of the current use of the
Distribution attribute indicates that we don't yet have enough experience
to be able to judge it.


On the subject of behaviour specified by the draft, there are a few places
where it should perhaps go further in dictating recommended behaviour. For
example, section 6.1 recommends that clients use the Unicode features of
Elvin `to ensure that user expectations are fulfilled' but provides no
guidance in how that should be achieved. If the draft is recommending that
all subscription references to the Group attribute should be wrapped in
decompose() (or decompose-compat()? and maybe fold-case() as well?) that
should be made explicit.

Additionally, I think the standard attribute copying behaviours when
replying to messages should be spelled out. For example, when sending a
reply a client should use the same Group value as was contained in the
message being replied to unless specifically instructed otherwise (which
is especially important if clients use transformation functions in their
Group subscriptions as above). Similarly, the Distribution of replies
should default to the same value as the Distribution of the message they
are in reply to.


Finally, on a minor note, section 11 refers to section 13 for contact
details, but should refer to section 14.

Ian