[ticker-dev] Timeout attribute
David Arnold
david at mantara.com
Sun Apr 11 21:08:11 CDT 2004
-->"Matthew" == Phillips, Matthew <Matthew.Phillips at dsto.defence.gov.au> writes:
Matthew> So, to get some closure here, how about I post my +1 for
Matthew> the "org.tickertape.message: 3001" proposal? Any
Matthew> dissenters?
I'm happy with this.
I've attached the current draft of the specification, updated to
reflect what I believe is the consensus position on all attributes.
This would be a good time for everyone to read it, carefully, cover to
cover, and object to anything you find objectionable :-)
d
-------------- next part --------------
INTERNET-DRAFT D. Arnold, Editor
tickertape.org
Expires: 12 Oct 2004 12 Apr 2004
Tickertape Chat Protocol version 3
draft-arnold-ticker-chat-v3-00.txt
1. Status of this Memo
This document is an Internet-Draft and is NOT offered in
accordance with Section 10 of RFC2026, and the author
does not provide the IETF with any rights other than to
publish as an Internet-Draft.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to
use Internet- Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be
accessed at http://www.ietf.org/shadow.html
2. Abstract
This document describes an Elvin message format as used
by the Tickertape family of applications. It supports
group-oriented, inter-person and machine-to-person
instant messaging and provides a simple, consistent
interface for presentation of a variety of interactive-
time data.
This specification is derived from a series of earlier
informal message format conventions, as documented in
Appendix B.
3. Terminology
This document refers to Elvin clients, producers, and
consumers; client libraries and routers.
An Elvin router is a daemon process that runs on a single
machine. It acts as a distribution mechanism for Elvin
Arnold Expires in 6 months [Page 1]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
messages. A client is a program that uses an Elvin
router, via a client library for a particular programming
language. A client library implements the Elvin proto-
cols and manages one or more connections to Elvin
routers.
The sender of an Elvin message is often referred to as a
`producer', and receivers as `consumers'. A single
client may perform either or both roles.
Further details of the Elvin protocol, its entities and
their roles is available in [ELVIN].
3.1. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be inter-
preted as described in [RFC2119].
4. Tickertape
The Tickertape family of applications provide person-to-
person and software-to-person instant messaging. As the
name suggests, the original user interface consisted of a
scrolling line of text, showing a series of messages.
Alternative styles of presentation have since become
available, but the name Tickertape has remained descrip-
tive of the whole family of applications which variously
support the creation, reception and often both, of
instant messages.
Producers support composition of messages and sending
them to a specified group. A particular message can be
sent independently, or as a reply to a preceding message.
Consumers subscribe to messages, often by group name, but
alternatively by some other combination of attributes of
the message.
Interactive clients normally display a subset of the
received messages' attributes, and facilitate composition
of initial or reply messages.
From its earliest prototypes, the facility has been used
by software to interact with human users. Both unidirec-
tional messages, such as hardware alerts, and automated
responders (or bots) have long formed a part of the Tick-
ertape culture.
What distinguishes Tickertape from other messaging appli-
cations and protocols such as [xy]talk, IRC, Jabber/XMPP,
Arnold Expires in 6 months [Page 2]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
and the various proprietary instant messaging systems, is
its ability to extend beyond a point-to-point, group or
channel-based communications using the content-based
routing abilities of the underlying Elvin transport.
4.1. Groups
The basic structural element of the Tickertape communica-
tions space is the concept of groups. A group is defined
by its name: a string that is specified by the message
producer, and this provides a basic point of context for
rendezvous with consumers. The group name performs the
role of a channel or forum, for selecting messages with
related content.
Most Tickertape clients maintain a persistent list of
group names which are simply selectable during message
composition. Many clients also allow group names to be
entered directly, allowing ad hoc group creation.
Group names need not be predefined, nor do they have any
required structure. Collisions between same-named groups
from previously unconnected administrative domains are
both possible and likely. Such collisions can be desir-
able: the two communities might share a common interest
or purpose. Where the collision is not productive, the
normal response is to restrict the distribution of mes-
sages in that group to within the administrative domain.
4.2. Sender Identity
Tickertape messages include the identity of the sending
entity as a string value.
While there are no constraints on the values that may be
used for this attribute, common usage has evolved several
conventions for the identity string:
Most clients default to using an identity string of the
form
user at domain
thus providing a simple distinction between users,
derived from the implicit uniqueness of their login name
in combination with their machine's domain name.
The obvious similarity with email addresses is not unin-
tentional. Rather than requiring a new naming scheme,
use of an email address reduces the likelyhood of colli-
sions, and takes advantage of users' familiarity with
this form of identifier.
Arnold Expires in 6 months [Page 3]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
However, a second convention has evolved that uses the
form
user at location
This usage, while similar in appearance, is quite dis-
tinct. One typical value for the location component is
the user's company name, which provides some level of
uniqueness, but is not as robust as a complete domain
name. However, a second common usage has the location as
"home", which provides very little distinction between
users.
These issues have not been addressed in the protocol
specification because no clear consensus has arisen that
it is a problem. Collision between identifiers does
occur, but it is resolved by social, rather than proto-
col, mechanisms.
5. Elvin
Tickertape uses Elvin as its underlying communications
layer. Elvin provides a one-to-any, publish/subscribe
transport with atomic, consistent per-source ordering,
best-effort delivery semantics. Defined mappings exist
for TCP, UDP and other bearer protocols.
Elvin messages are structured, using a flat name space of
basic data types, including Unicode strings. Messages
are transmitted to an Elvin router, where they are com-
pared against the registered subscriptions. A copy of
the message is delivered to the owner of each matching
subscription and to other connected routers.
Subscriptions are expressed as predicates in a simple, C-
like syntax. In addition to the usual comparison and
arithmetic operators, functions are provided to test the
existence and type of values, to perform case folding and
normalisation, and for regular expression and glob-style
wildcard matching.
Further details of the protocol and subscription language
are available in [ELVIN].
6. Message Specification
This document specifies the basic Tickertape 'chat' mes-
sage format. Several other message formats are fre-
quently implemented by a Tickertape client, for example
that for presence notifications [PRESENCE].
Arnold Expires in 6 months [Page 4]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
A Tickertape chat message has three fundamental proper-
ties: the sending entity's name, a specified target
group, and a textual message body. These basic proper-
ties are then augmented to allow message ageing, threaded
conversations, attachments and other features.
6.1. Base Attributes
The base attributes MUST be present in all Tickertape
chat messages.
Name Type Description
-----------------------------------------------------------------
Group string The name of the group to which this mes-
sage is sent.
From string The name of the sender of the message.
Message string Text to be displayed in the scroller (or
similar user interface location).
Message-Id string A globally unique identifier for this mes-
sage.
The use of some combination of host name,
process identifier and time of day (for
example a GUID or UUID), hashed (using
SHA.1, MD5, etc) to ensure anonymity is
RECOMMENDED.
-----------------------------------------------------------------
Tickertape client applications typically provide the
ability to subscribe to messages using the 'Group' name,
and frequently arbitrary subscriptions over the 'From',
'Message' and other attributes.
String-valued Elvin attributes use the UTF-8 [RFC2279]
Unicode [UNICODE] character encoding. In some cases, a
single character may have multiple representations in
Unicode. As an example, a base character combined with
an accent can sometimes have a single code for the combi-
nation, or use multiple codes to represent the base char-
acter plus a combining accent.
The Elvin subscription language provides operations to
transform strings to canonical representations to ensure
that strings using different representations of the same
characters are correctly matched. Implementors of Tick-
ertape protocol clients SHOULD use these features to
ensure that user expectations are fulfilled.
Arnold Expires in 6 months [Page 5]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
6.2. Replies and Intra-group Threads
When sending a message as a reply to a previously
received message, implementations MUST identify that mes-
sage as a means of supporting presentation of conversa-
tions in order.
Name Type Description
---------------------------------------------------------------
In-Reply-To string The Message-Id of a previous message to
which this is a reply.
---------------------------------------------------------------
6.3. Private or Extra-group Threads
It is possible to send messages directed to a group to
which the sender is not subscribed. This is commonly
used when the sender wants to initiate a convesation with
the user(s) of the channel, but does not want to see
traffic on that channel from other conversations.
The sender includes a Thread-Id attribute in the initial
message, and temporarily subscribes to all messages with
a matching Thread-Id value.
Responding clients copy the received Thread-Id value into
any replies made to that message, and thus the responses
are visible to the original poster.
A client responding to a message containing a Thread-Id
attribute MUST include a Thread-Id attribute with that
value in its response.
Name Type Description
----------------------------------------------------------------
Thread-Id string When sending a message to a group to which
the sender is not subscribed but wishes to
see any replies, this field should be set
(and the sender's user agent should alter
its subscription so as to receive any mes-
sages with this Thread-Id value).
This value must be globally unique. See
Message-Id for recommendations.
----------------------------------------------------------------
6.4. Optional Attributes
The following attributes MAY be included, at the discre-
tion of the application writer or controlling user.
Arnold Expires in 6 months [Page 6]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
6.4.1. Protocol Version
Elvin messages are sufficiently self-descriptive that
applications can be written to cater for missing or addi-
tional attributes to those expected. It is therefore not
necessary for robust communication that the protocol ver-
sion in use be formally specified.
However, if a producer wishes to indicate that it sup-
ports this specification, it MAY do so using the follow-
ing attribute.
Note that this information is purely informative, and an
application MUST NOT fail because of a discrepancy
between the version indicated with this attribute, and
the format of the message.
Name Type Description
------------------------------------------------------------------
org.tickertape.message int32 The version of this specifica-
tion implemented by the message.
For this revision, the value
MUST be an Elvin int32, with a
value of 3001.
------------------------------------------------------------------
6.4.2. Message Validity
For Tickertape consumer applications, it is sometimes
useful to have an indication of the valid or useful
lifespan of a message. This attribute allows the pro-
ducer to suggest a time period after which the message
might be removed from the display or otherwise depriori-
tised.
A positive value suggests that the message be removed
from display after that many seconds. Clients MAY inter-
pret this value liberally; a resolution in the order of
minutes is normally adequate.
Special interpretation SHOULD be applied for a value of
zero, indicating that the message be shown briefly; and
negative values, suggesting that it not be shown at all,
but displayed only in logs or historical views.
Name Type Description
-------------------------------------------------------------
Timeout int32 Suggested lifetime of the message, in sec-
onds.
-------------------------------------------------------------
Arnold Expires in 6 months [Page 7]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
6.4.3. User Agent Identification
User agents (clients) MAY identify themselves as the
sending agent of Tickertape messages. If they do, this
attribute SHOULD be used for that purpose.
Name Type Description
-------------------------------------------------------------
User-Agent string The name and version of the user agent
(program) generating this message.
-------------------------------------------------------------
6.4.4. Archiving
One common class of Tickertape consumer programs makes a
permanent record of message traffic, usually on a per-
channel basis. Producers can optionally allow the user
to indicate that a message should not be archived in this
manner.
Archiver clients SHOULD implement support for this
attribute, and SHOULD NOT store messages for which it
exists, and has a non-zero value.
Name Type Description
--------------------------------------------------------------
No-Archive int32 The sender of a message can request that
it not be archived by setting this
attribute with a non-zero value.
--------------------------------------------------------------
6.4.5. Distribution
This attribute is intended for interpretation by forward-
ing filters at administrative boundaries and describes
restrictions on the distribution of this message.
No constraints are set on the value of this field, but
examples might include "local", the company name,
"unclassified", etc.
Note that no global interpretation is placed on the val-
ues of this field. Its meaning is defined within an
administrative domain, to be interpreted at its adminis-
trative boundaries. Multiple levels of such interpreta-
tion are possible.
Future standardisation of the semantics of this attribute
is likely.
Arnold Expires in 6 months [Page 8]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
Name Type Description
-------------------------------------------------------------------
Distribution string A value, intended for interpretation by
forwarding filters at administrative
boundaries, describing restrictions on the
distribution of this message.
No constraints are set on the value of
this field, except that it SHOULD have a
string value.
-------------------------------------------------------------------
6.4.6. Attachments
In addition to the simple textual message content, it is
often useful to attach URLs, file references, sounds,
email addresses or other content to a Tickertape message.
This attribute provides a means to attach additional con-
tent encoded using the MIME standards [RFC2045-RFC2049].
Note that this field is an Elvin string type, and thus
its value must be legitimate UTF-8. The MIME specifica-
tion provides various options for encoding data which is
not compatible with its containing protocol (ie. base64
encoding, see [RFC1421] section 4.3.2.4). One of these
mechanisms MUST be used to ensure that binary content is
safely transported.
In choosing to use a string type for this attribute, our
major motivation was to enable subscription to the
attached information (where it is in un-encoded form).
This includes things like the MIME content types, etc.
Content that is valid UTF-8 SHOULD NOT be additionally
encoded so as to facilitate subscription to messages by
their attached content.
The most common form of attachment is a URL. URLs SHOULD
use the text/uri-list MIME type. Multiple attached
objects can be encoded using the multipart/mixed MIME
type.
Name Type Description
----------------------------------------------------------------
Attachment string A MIME-encoded addition to the message.
Note that this value must be a legitimate
UTF-8 Unicode string, and consequently,
binary values must be encoded using, for
example, base 64 encoding.
----------------------------------------------------------------
Arnold Expires in 6 months [Page 9]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
6.4.7. Updating Existing Messages
In a scrolling user interface, it can be useful to have
messages that are constantly visible, but whose content
is updated over time. An example of such a message might
be the current score in a sporting event.
A producer application that wishes to enable such
replacement MAY include this field in sent messages. The
value MUST be globally unique unless the message is
intended to replace a previous message; see Message-Id
for recommended practice in generating unique identi-
fiers.
A consumer application that wishes to allow update of
currently displayed messages should compare the value of
an arriving message's Replaces field with those of exist-
ing messages. The attributes of the arriving message
should replace those of any previous message(s) with
matching Replaces value(s).
If no currently displayed message's Replaces field
matches this value, the arriving message is presented as
usual.
Name Type Description
--------------------------------------------------------------
Replaces string An identifier, either unique to this mes-
sage, or matching a previous message's
Replaces value.
--------------------------------------------------------------
7. Access Control
Elvin supports the use of keys to control visibility of
both messages and subscriptions [ELVIN]. This specifica-
tion does not mandate the use of a particular key scheme,
or a method of applying the general Elvin access control
facilities to Tickertape Chat messages.
It is likely that a companion document, or a future revi-
sion of this document, will describe such a method.
8. Security Considerations
8.1. Access Control
Unless a Tickertape client uses a proprietry method to
constrain the visibility of Tickertape messages using
Elvin access control, all messages and subscriptions
should be considered exposed to any user with access to
Arnold Expires in 6 months [Page 10]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
the supporting Elvin router infrastructure.
8.2. Sender Identity
The presented user identity, obtained from the From
attribute of the message, can be either empty or mislead-
ing.
8.3. Attachments
The optional use of the 'Attachment' attribute to deliver
a MIME-encoded object allows arbitrary data to be deliv-
ered to the receiver's machine. This data can be inter-
preted by the client program, and this interpretation
could involve the execution of arbitrary code.
Client application developers and end-users should ensure
that the interpretation of MIME data occurs within appro-
priate safeguards.
Some user agents also provide a facility to automatically
invoke the interpretation of MIME attachments. This
practice introduces an additional risk, precluding a man-
ual vetting of the data before interpretation.
8.4. Message Replacement
The use of the 'Replaces' attribute to update a previous
message's content can be abused by an attacker to rewrite
any replaceable message.
8.5. Denial of Service
It is possible to attack either an individual Tickertape
client, or the Elvin routing network, by sending a large
number of Tickertape messages.
This type of attack could impact local network bandwidth,
Elvin router latency and CPU usage, and Tickertape client
host CPU usage.
The combination of many messages and automatically
invoked attachment interpretation has particularly high
risk of substantial impact.
9. IANA Considerations
This specification places no requirements on the IANA.
10. Relevant Publications
The Elvin client protocol [ELVIN] defines an abstract
protocol for communication between Elvin clients and
Elvin routers, and concrete protocols for TCP-based
Arnold Expires in 6 months [Page 11]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
transport and XDR-based data marshaling.
A recommended extension to [ELVIN] providing automatic
router discovery is defined in [ERDP].
An inter-router protocol wide-area routing [ERFP] are
also available. Elvin router implementations normally
support federation.
11. Contact for further information
See section 13 for full contact details.
12. Author/Change controller
This specification is a product of the informal Ticker-
tape developer community. It is derived from work origi-
nally done at DSTC (www.dstc.com), and now conducted
through the facilities of tickertape.org with the cooper-
ation of Mantara Software.
Suggested revisions or extensions to this specification
should be sent to the working group, at the address
listed in section 13.
Arnold Expires in 6 months [Page 12]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
13. REFERENCES
[ELVIN] D. Arnold, Editor, "Elvin Client Access Proto-
col", Work in progress
[ERDP] D. Arnold, J. Boot, T. Phelps, B. Segall, "Elvin
Router Discovery Protocol", Work in progress
[ERFP] D. Arnold, I. Lister, "Elvin Router Federation
Protocol", Work in progress
[RFC1421] J. Linn, "Privacy Enhancement for Internet Elec-
tronic Mail: Part I: Mesage Encryption and
Authentication Procedures", RFC1421, February
1993.
[RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of
Internet Message Bodies", RFC2045, November
1996.
[RFC2046] N. Freed, N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC2046, November 1996.
[RFC2047] K. Moore, "Multipurpose Internet Mail Extensions
(MIME) Part Three: Message Header Extensions for
Non-ASCII Text", RFC2047, November 1996.
[RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Reg-
istration Procedures", RFC2048, November 1996.
[RFC2049] N. Freed, N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples", RFC2049, November 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indi-
cate Requirement Levels" RFC2119, March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syn-
tax Specifications: ABNF", RFC 2234, November
1997.
Arnold Expires in 6 months [Page 13]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
[RFC2279] F. Yergeau, "UTF-8, a transformation format of
ISO 10646", RFC 2279, January 1998.
[RFC2483] M. Mealling, R. Daniel, Jr, "URI Resolution Ser-
vices Necessary for URN Resolution", RFC 2483,
January 1999.
[UNICODE] Unicode Consortium, The, "The Unicode Standard,
Version 4.0", Addison-Wesley, Reading, MA, 2003,
ISBN 0-321-18578-1.
14. Contact
Editor's Address
David Arnold
tickertape.org
Email: ticker-dev at tickertape.org
Contributors
David Arnold
Julian Boot
Phil Cook
Anna Gerber
Michael Henderson
Michael Lawley
Ian Lister
Thomas Maslen
Ted Phelps
Matthew Phillips
Clinton Roy
Bill Segall
Martin Wanicki
Arnold Expires in 6 months [Page 14]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
15. Full Copyright Statement
Copyright (C) 2003-2004 by tickertape.org.
Copyright (C) 2001-2003 DSTC Pty Ltd.
All Rights Reserved.
This specification may be reproduced or transmitted in
any form or by any means, electronic or mechanical,
including photocopying, recording, or by any information
storage or retrieval system, providing that the content
remains unaltered, and that such distribution is under
the terms of this licence.
While every precaution has been taken in the preparation
of this specification, the authors assume no responsibil-
ity for errors or omissions, or for damages resulting
from the use of the information herein.
Comments on this specification are welcome. Please
address any queries, comments or fixes (please include
the name and version of the specification) to the mailing
list below:
ticker-dev at tickertape.org
Elvin is a trademark of Mantara Software. All other
trademarks and registered marks belong to their respec-
tive owners.
Arnold Expires in 6 months [Page 15]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
Appendix A - Example Notifications
This section shows some example notifications using pre-
vious versions of the Tickertape specification, and com-
pares them with their representation using this version
of the specification.
Consider a simple message, with an attached URL:
Message-Id: "1d906567-e491-48c6-9607-1b9f79f926da"
TICKERTAPE: "Chat"
TICKERTEXT: "check this out!"
USER: "Spammeister"
TIMEOUT: 5
MIME_TYPE: "x-elvin/url"
MIME_ARGS: "http://www.spamradio.net"
This would now be sent as
Message-Id: "1d906567-e491-48c6-9607-1b9f79f926da"
Group: "Chat"
Message: "check this out!"
From: "Spammeister"
Timeout: 300
Attachment: "MIME-Version: 1.0\r\n" \
"Content-type:text/uri-list\r\n" \
"\r\n" \
"http://www.spamradio.net\r\n"
User-Agent: "Example Ticker v1.0"
The Attachment field is the most changed. It has been
renamed, and is now a proper MIME document, rather than
putting only the content type and the data as separate
attributes.
This makes for simpler handling using standard library
facilities, and enables the proper use of all features
from the MIME standards.
Note also the recommended change from the experimental
"x-elvin/url" content type, to the standard type
"text/uri-list" when attaching a URL to a message.
Also note that the Timeout field has changed from using
units of minutes, to seconds. While minutes are suffi-
cient resolution for this application, in other Elvin
applications, Timeout normally uses seconds, and so that
usage is adopted here.
Arnold Expires in 6 months [Page 16]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
Appendix B - Previous Versions
The protocol specified by this document has undergone
several years of evolutionary development. Several dozen
implementations exist, with varying levels of functional-
ity and compatibility.
The naming for attributes in this specification is delib-
erately different from previous versions, in an attempt
to both enable backward compatibility and to encourage
migration to current best practice for Elvin applica-
tions.
Basic Attributes
The basic attributes have remained unchanged since the
first implementation of the Tickertape protocol for Elvin
3. All subsequent revisions have expanded on this basic
set.
Name Type Description
-------------------------------------------------------
TICKERTAPE string The name of the group to which
this message is sent.
USER string The name of the sender of the
message.
TICKERTEXT string Text to be displayed in the
scroller (or similar user inter-
face location).
TIMEOUT int32 Suggested lifetime of the mes-
sage, in minutes, mostly useful
for scrolling presentation.
-------------------------------------------------------
Attachments
The attachment of URLs to Tickertape messages was popu-
larised using a debased form of MIME-style encoding. Few
clients supported MIME types other than the informal 'x-
elvin/url' type.
Name Type Description
---------------------------------------------------
MIME_TYPE string The MIME type of the attached
data.
MIME_ARGS string The body of the MIME object.
---------------------------------------------------
Arnold Expires in 6 months [Page 17]
Internet Draft Tickertape Chat Protocol v3 12 Apr 2004
Replacement
Replacement of previous messages was introduced to sup-
port sports scores and similar situations where a con-
stantly updating value should not generate a new pre-
sented message for each update.
Name Type Description
--------------------------------------------------------
REPLACEMENT string A string identifier. Subsequent
messages with the same REPLACE-
MENT value should replace this
message when presented.
--------------------------------------------------------
Threads
The most recent addition to be widely implemented used
message identifiers to allow a client to present
responses to previous messages in order. This reflects
the introduction of clients with tablular presentation
instead of or in addition to a scrolling interface.
Name Type Description
--------------------------------------------------------
Message-Id string A string identifier for this
message. Use of a UUID (GUID)
is suggested.
In-Reply-To string A string identifier for the mes-
sage to which this is a
response.
--------------------------------------------------------
No other attributes have been widely accepted by develop-
ers of Tickertape clients to date. This document repre-
sents the first formal standardisation of the protocol,
and codifies best-practice as developed by the Tickertape
community over the course of these enhancements.
Arnold Expires in 6 months [Page 18]
More information about the ticker-dev
mailing list