[ticker-dev] Latest draft

[David Arnold]

-->"Ian" == Ian Lister <ticker-lists at lister.dnsalias.net> writes:

  Ian> <...> I would like to set aside an appropriate attribute name
  Ian> for any protocol or application for which the Message-Id based
  Ian> methods is more appropriate (or which would like to use both
  Ian> methods). The reason I would like to do this as part of the
  Ian> Ticker spec process is that it may turn out that `Replaces' is
  Ian> the most appropriate name for this, and it would be better to
  Ian> use a different name for the Ticker-style method. Does anybody
  Ian> have any alternate name suggestions for either?

I think the name "Replaces" is a relic from the replace-by-id proposal.

If I was to start from scratch, I'd suggest something like

  Replacement-For-Message-Id
  Replacement-Id

Do sticker, aquatik or eTiks support Replaces/Replacement/REPLACEMENT ?

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

The field is optional, so my reading would make this interpretation
natural from the spec text itself .. if you have no need to indicate a
useful lifetime of a message, then don't use a Timeout.

Obviously existing clients tend to always include it, if only for
reasons of unthinking compatibility with the original Elvin3 Python
Tickertape GUI :-)

I'm not sure this should be pushed via the spec?  But maybe?

  Ian> The Distribution attribute is the only other one covered by the
  Ian> draft that I am uncertain about. Sticker uses CLASSIFIED and
  Ian> UNCLASSIFIED (and now `world'?) and DSTO filters traffic based
  Ian> on it, but I'm not aware of any other client implementation or
  Ian> organisation using it.

Yet .. I'm fairly tempted to start Mantara using this, for example on
"Chat" ...

  Ian> I'm not particularly familiar with Sticker but IIRC it has a
  Ian> toggle control to choose between the two values, which are
  Ian> hard-coded into the application rather than configurable by the
  Ian> organisation (perhaps this has changed since I last looked
  Ian> though).

I think the values used to be set in a properties file?  But I think
you're right in that it uses a toggle button .. Matthew?

  Ian> It seems to me that any implementation which provides the
  Ian> functionality intended by the draft (that is, to allow
  Ian> organisations to define distribution scopes and to allow scopes
  Ian> to be chosen on a user's per-message basis rather than an
  Ian> administrator's per-channel basis) will be significantly more
  Ian> complicated, probably introducing a pull-down menu of known
  Ian> scopes. Currently, having the user select the correct channel
  Ian> can be difficult enough - with issues about discovering
  Ian> channels, getting the name exactly right (with associated case
  Ian> sensitivity nastiness), choosing the correct channel for the
  Ian> correct message (not leaking onto an inappropriate channel),
  Ian> etc - and it seems that introducing a scope menu would have all
  Ian> the same issues (currently without the equivalent of the
  Ian> presence protocol to discover scopes that other people are
  Ian> using) and would be similarly important in getting messages to
  Ian> the right people.

I was disucssing this with Bill the other day, in the context of
adding support for Distribution to xticker.

We wanted two basic things:

a) A reply to a message should default to the same Distribution as the
   original message

b) Any message (reply or otherwise) using a non-default scope should
   highlight that fact fairly blatantly (not as blatanly as a
   confirmation dialog, but ... think vivid red panel or something)

DSTC is one organisation that has (or used to have) three distribution
scopes: internal, participant, and public, as an example.  So
something more than a simple toggle would be required there.

There are a bunch of UI issues here which I don't think sticker (or
eTiks, etc) has fully explored.

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

In general, I agree that a formal specification for Distribution is
probably premature.  I think the weasel words wrt legal values reflect
this.

My suggestion would be to move to it from its current position as
"Optional" into a new section, "Experimental".

I think there's some value in leaving it in the specification, so that
at least we're noting the fact that there's a general concensus (and
some implementation experience) with the field as named, although we
might not be confident that it is in its final form?


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

A good question :-)

I'm one of those people who is happy that "Chat" and "chat" are
different things.  I know there exist many people who think they're
sufficiently similar that they should be considered the same thing in
contexts like this.

OTOH, there is historical precedent for not doing fold-case() on Group.

Anyone want to oppose the forces of history on this?

I'm unaware of any historical precedent for decomposition.  Being an
English-speaker, I'm hardly in a position to judge, but I'd probably
suggest decompose-compat() if I had to guess.  Anyone?


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

The Thread-Id behaviour could also be noted in such a section.

I'll draft something.

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

Oops.  I must M4 that one.  Thanks.




d