[ticker-dev] Latest draft

[Ian Lister]

On Tue, 13 Apr 2004, David Arnold wrote:
>I think the name "Replaces" is a relic from the replace-by-id proposal.

It does seem more appropriate for that, yes. (Which is of course why I
raised it :-)

>If I was to start from scratch, I'd suggest something like
>
>  Replacement-For-Message-Id
>  Replacement-Id

Would you be interested in renaming the current Replaces then?

[Re: Timeout]
>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.

I see what you're saying, but my reading of the fact that it's optional is
just to say `you can do this if you want' but that doesn't really imply
`you shouldn't do this unless you have a good reason', and I think it's
worth making the second part explicit.

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

I think existing clients tend to always include it because (a) of a `more
is better' perception (it's optional, and I _can_ do it easily enough, so
I should), and (b) everybody else does (more about following the herd than
compatibility).

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

I could possibly be convinced that it shouldn't, but currently I think
it's well within the scope of the spec to be making clear anything
(including implementation issues) that improves the effectiveness of the
protocol.

>  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" ...

My point was not that it's not generally useful, just that it's not
generally used (yet), and I am reluctant to standardise (even in a
weasel-word way) anything that we don't have enough experience with to be
confident in.

>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

I think that's pretty much a given (and is something the spec should make
explicit).

>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)

So I would have Chat configured by default to be Mantara-internal, and any
conversation I have on `chat.world' (Group: "Chat" Distribution: "world")
would have vivid red over everything? Hmmm... could be a lot of UI
experimentation there to get something that works well :-)

>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.

Definitely. The mechanism is designed to support an arbitrary set of
values and I think that for the purposes of interoperability that means
all clients are going to need to support that too.

Note that this isn't strictly an optional extra to the protocol; I think
any interactive client MUST support it at least to the extent that any
Distribution is copied from original message to reply. Otherwise there
will be breakage where a user replies to a message on `chat.world' and
sees their own reply but nobody on the other side of any administrative
boundary does.

Note that a client such as psst (which has the consumer and producer
components completely separated) is fundamentally unable to do this.

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

I agree.

>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".

Yep, I think that's something along the lines of what I was thinking of.
Either that or add it later as subsequent additional spec (but note the
observation above that this isn't going to work unless all clients
support it to some extent).

>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?

I think if we're not confident that it's right yet (or may change) it
probably shouldn't be covered in the spec in any formal way.

[Re: using the Unicode features of Elvin to fulfil user expectations]
>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.

And historical evidence that it causes problems, even with users who are
well aware of the need to be careful of case. I'm not aware of any cases
where it has proved to be an advantage.

Fortunately the negative transitional effects of making the change would
(IMO) be reaonsably small, and limited to users of old clients
potentially not seeing messages sent by new clients on channels with
different case. As long as replies copy the group name from the original
message then this should be kept to an absolute minimum.

Note that this is the same as introducing any recommendation of
decomposing group names in subscriptions.

>Anyone want to oppose the forces of history on this?

Well, the historical precedent is for us to break stuff willy-nilly in the
name of making it better for the future, so given the small impact I'm not
too concerned about the negative effects of changing 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?

So what exactly was the last paragraph of section 6.1 recommending?

On Tue, 13 Apr 2004, Bill Segall wrote:
>Experimental would seem like a great plan from the specification
>viewpoint. I think this could go a long wat to encourage a new era of
>trying things out. I suspect that part of the problem is that we're way
>too focussed on getting this spec "right". Perhaps we should just close
>it out and then start on the next version. Specs are great things but
>there needs to be revisions and new versions as well.

I definitely agree. The problem with Distribution is that it requires
_all_ clients to support it for it to work properly :-/

On Wed, 14 Apr 2004, David Arnold wrote:
>  michael> In fact, this concept may also improve the idea of the
>  michael> <username> channel if things were switched around to be the
>  michael> "personal" channel with Distribution <username>.
>
>This would only really work if organisations were happy to use a
>default-allow policy.  Internal-only traffic would need to have
>Distribution "internal" (or whatever) and would be blocked at the
>organisational boundary.

I think any significant administrative boundary (such as at the boundary
of a company) would have to have a default-deny on Distribution. Of
course, the problem is dealing with messages that don't have specified
Distributions without but-not().

>The other question is whether the Distribution value should be a list,
>or a single value.  I'm not sure there's a good use for a list ... ?

I can see quite a few uses, but it always seems so ugly in the absence of
native lists.

One good example of a use would be where we have a group for communication
with a specific customer or participant. In that case the distribution
should list the two specific organisations involved. Another is Bill's
example of communicating with a specific person.

However, it's not clear whether these problems are best solved with
Distribution or with some other approach (keys, Reply-To, etc).

Ian