From bill at dstc.edu.au Mon Sep 17 14:18:04 2001 From: bill at dstc.edu.au (Bill Segall) Date: Tue Oct 14 08:01:37 2003 Subject: A more personal welcome to ticker-dev Message-ID: <200109170418.f8H4I4b19567@piglet.dstc.edu.au> Welcome to ticker-dev :-) I'd like to again thank everyone for their contributions last week and to especially thank Michael Henderson for all the work that brought it together. To help kick off this list ... I was asked to contribute some thoughts about a couple of extra fields in tickertape notifications and I thought I might begin with that. 'X-no-archive' ... I'd like the spec to have a optional field that acts to tell programs that log tickertape messages not to archive the particular message. Many mailing lists support an X-no-archive field and I think we should adopt it. There is no enforcement other than ethical. 'Distribution' I think that it would be desirable to have a field that acts a hint for distribution across federations. Possible values might include: { local, organization, world, secure, classified } etc. This is badly thought out at the moment but I was hoping that by raising it others might have suggestions ... Bill. From julian at dstc.monash.edu.au Mon Sep 17 14:23:55 2001 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag (was Re: [ticker-dev] A more personal welcome...) In-Reply-To: <200109170418.f8H4I4b19567@piglet.dstc.edu.au> Message-ID: <200109170424.f8H4O1700010@xevious.dstc.monash.edu.au> Bill Segall wrote: > 'Distribution' > > I think that it would be desirable to have a field that acts a hint for > distribution across federations. Possible values might include: { local, > organization, world, secure, classified } etc. This is badly thought out at > the moment but I was hoping that by raising it others might have > suggestions ... this seems like producer specified routing and goes against the content based routing of elvin. if you want to limit distribution, i'd be more interested in looking at the interaction of local tickertape messages with a adminstratively controlled gateway and the use of keys to enforce policy. -J From ilister at dstc.edu.au Mon Sep 17 14:28:21 2001 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:37 2003 Subject: No-archive tag (was Re: [ticker-dev] A more personal welcome toticker-dev) In-Reply-To: <200109170418.f8H4I4b19567@piglet.dstc.edu.au> Message-ID: On Mon, 17 Sep 2001, Bill Segall wrote: >To help kick off this list ... I was asked to contribute some thoughts >about a couple of extra fields in tickertape notifications and I thought I >might begin with that. > >'X-no-archive' ... Without going into the purpose of this attribute, there's no reason for it to have an `X-' prefix (the only reason it has one in NNTP is that it's not a standard header), and I believe our current `best-practice' naming would leave it as `No-Archive'. Other than that, I think it sounds OK :-) Ian `retentive' Lister :-) From Matthew.Phillips at dsto.defence.gov.au Mon Sep 17 14:46:52 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag (was Re: [ticker-dev] A more personal welcome...) Message-ID: <2149A0BABC77D311AF890090274E00B203A1EAD5@salex005.dsto.defence.gov.au> > Bill Segall wrote: > > > 'Distribution' > > > > I think that it would be desirable to have a field that > acts a hint for > > distribution across federations. Possible values might > include: { local, > > organization, world, secure, classified } etc. This is > badly thought out at > > the moment but I was hoping that by raising it others might have > > suggestions ... > > this seems like producer specified routing and goes against > the content > based routing of elvin. if you want to limit distribution, i'd be > more interested in looking at the interaction of local > tickertape messages > with a adminstratively controlled gateway and the use of keys > to enforce > policy. I can't see why producers shouldn't include hints as to how useful a message is to a given domain of use. Clients can still opt to receive everything if they want to. Matthew. From philc at csee.uq.edu.au Mon Sep 17 14:52:49 2001 From: philc at csee.uq.edu.au (Phil Cook) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag (was Re: [ticker-dev] A more personal welcome...) In-Reply-To: <200109170424.f8H4O1700010@xevious.dstc.monash.edu.au> Message-ID: <01091714525305.27757@morgan> On Monday 17 September 2001 14:24, Julian Boot wrote: > Bill Segall wrote: > > 'Distribution' > > > > I think that it would be desirable to have a field that acts a hint for > > distribution across federations. Possible values might include: { local, > > organization, world, secure, classified } etc. This is badly thought out > > at the moment but I was hoping that by raising it others might have > > suggestions ... > > this seems like producer specified routing and goes against the content > based routing of elvin. if you want to limit distribution, i'd be > more interested in looking at the interaction of local tickertape messages > with a adminstratively controlled gateway and the use of keys to enforce > policy. I have to agree with Julian on this one. "Hints" of this form scare me somewhat. For example, the window manager hints in X have turned out to be a bit of a disaster: every WM implements different hints, and implements hints differently. Hints shouldn't play a role in the core effect of a notification - if there is a real routing problem here, it should be solved by Elvin itself (which also lets other protocols exploit it). A hint like X-No-Archive, however, is fine, as I would not call archiving part of the "core" effect of a notification. This is, perhaps, where X stumbled: the original designers probably didn't see WM behaviour as a core aspect of X, but today I believe most users would regard this behaviour as core. Phil. _____________________________________________________________________________ Phil Cook "No Neil, after you" Ph.D. student at large - Buzz Aldrin School of Computer Science & Electrical Engineering The University of Queensland, QLD, 4072, Australia From ilister at dstc.edu.au Mon Sep 17 14:57:23 2001 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag (was Re: [ticker-dev] A more personal welcome...) In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EAD5@salex005.dsto.defence.gov.au> Message-ID: On Mon, 17 Sep 2001, Phillips, Matthew wrote: >I can't see why producers shouldn't include hints as to how useful a message >is to a given domain of use. Clients can still opt to receive everything if >they want to. Tickertape is a little different in this regard to other Elvin applications in that it is not as content-based. An ideal notification allows the routing infrastructure to be able to determine where it should be sent, but Tickertape notifications are more or less free-form text entered by humans. In fact, the group name is about the only thing that can be used to reliably route (or block) on. Given this, I think it is at least more reasonable to allow producers the option to give routing (or at least scope) information in Tickertape than in other Elvin applications. Having said that, I'm going to reserve my decision on whether I think it's a good idea :-) Ian From julian at dstc.monash.edu.au Mon Sep 17 15:41:01 2001 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag (was Re: [ticker-dev] A more personal welcome...) In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EAD5@salex005.dsto.defence.gov.au> Message-ID: <200109170541.f8H5f7700327@xevious.dstc.monash.edu.au> "Phillips, Matthew" wrote: > I can't see why producers shouldn't include hints as to how useful a message > is to a given domain of use. Clients can still opt to receive everything if > they want to. not if those notifications we dropped a few hops ago because a federator used them as "a hint for distribution across federations". this is a general elvin-philosophy: producers should never attempt to second guess how a notification will be used. even allowing for tickertape as a non-elvin application, adding a Distribution tag does not seem any more effectual than using selective naming of tickertape groups. perhaps a Domain tag could be useful, as a one level hierarchy of group names, maybe...? The differnce between a Domain tag and a Destination tag is that the former describes something about the producer while the latter describes a property of the consumer. The latter is Bad(tm) in elvin... next, we'll be talking about a Servers field which has the urls of elvinds to insert copies of the notification into... ;-) perhaps bill could explain exactly what goal the Distribution tag is aimed at delivering? do we currently have a problem with distribution across federators that security cannot fix better? is it just that the use of security is lagging behind the deployment of federated elvinds? is that 0.04c now? -J From arnold at dstc.monash.edu.au Mon Sep 17 16:31:07 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:37 2003 Subject: Distribution tag In-Reply-To: <200109170541.f8H5f7700327@xevious.dstc.monash.edu.au> Message-ID: <200109170631.f8H6VD700549@xevious.dstc.monash.edu.au> -->"Julian" == Julian Boot writes: Julian> "Phillips, Matthew" wrote: >> I can't see why producers shouldn't include hints as to how >> useful a message is to a given domain of use. Clients can still >> opt to receive everything if they want to. Julian> not if those notifications we dropped a few hops ago because Julian> a federator used them as "a hint for distribution across Julian> federations". in *general*, this is no different from a federator dropping them because they were to the "frobnitz" group, which was not forwarded a few hops ago. Julian> this is a general elvin-philosophy: producers should never Julian> attempt to second guess how a notification will be used. that's true. there's also: producers should feel free to put whatever information they feel relevant into their notifications. and: consumers should feel free to subscribe to any property of available events. Julian> The differnce between a Domain tag and a Destination tag is Julian> that the former describes something about the producer while Julian> the latter describes a property of the consumer. The latter Julian> is Bad(tm) in elvin... i think this is the core of the issue. there's nothing wrong with producers adding any information they have to the notification. inter-domain links are free to filter whatever they like, using whatever fields they like. in this case, the producer is expressing an opinion about the relevance of the data produced. it is perhaps poorly expressed, but the intention is ok, imo. but ... a field value of "local" is not very meaningful in a global context. while in the majority of cases the end result is the same (ie. they'll get dropped at the admin boundary), if they are not dropped, a value of "local" (or any other geographically relative term) is meaningless at best (and misleading at worst). use of a domain tag is slightly dubious because it reduces anonymity. it's also not clear that it enables the same conceptual functionality. use of a security key would allow universal routing, but requires pre-distribution of the key (unlike a distribution tag). use of a list of "domains" in which the info was valid/relevant (ie. "dstc,qld,au,world") *might* achieve what was desired, but it's not clear if there was an hierarchical containment implicit in the values from "local" to "world". Julian> perhaps bill could explain exactly what goal the Julian> Distribution tag is aimed at delivering? i guess there's some scenario that triggered this request, which might be worth some more detail. i'm not convinced that a Usenet-style "Distribution" tag is a useful addition to Tickertape, at this stage. perhaps this whole debate is symptomatic of the basic clash between between filtering and content-based routing? any gateway that explicitly filters traffic hinders CBR. the name of the property used to do so is not really important. d From julian at dstc.monash.edu.au Mon Sep 17 16:54:54 2001 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Distribution tag In-Reply-To: <200109170631.f8H6VD700549@xevious.dstc.monash.edu.au> Message-ID: <200109170655.f8H6t0700674@xevious.dstc.monash.edu.au> David Arnold wrote: > Julian> The differnce between a Domain tag and a Destination tag is > Julian> that the former describes something about the producer while > Julian> the latter describes a property of the consumer. The latter > Julian> is Bad(tm) in elvin... > > i think this is the core of the issue. yes, but we seem to have crossed lines. I was not suggesting renaming Distribution to Domain. > use of a list of "domains" in which the info was valid/relevant > (ie. "dstc,qld,au,world") *might* achieve what was desired, but it's > not clear if there was an hierarchical containment implicit in the > values from "local" to "world". this is the same is Distribution. Domain was suggested as a "producer" attribute. and would contain eg "DSTC", "Monash", etc. thus domain.group provides hierarchical naming scheme, albeit virutal. > i guess there's some scenario that triggered this request, which might > be worth some more detail. i'm not convinced that a Usenet-style > "Distribution" tag is a useful addition to Tickertape, at this stage. agreed. -J From arnold at dstc.monash.edu.au Mon Sep 17 17:07:34 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Distribution tag In-Reply-To: <200109170655.f8H6t0700674@xevious.dstc.monash.edu.au> Message-ID: <200109170707.f8H77e700703@xevious.dstc.monash.edu.au> -->"Julian" == Julian Boot writes: Julian> yes, but we seem to have crossed lines. I was not Julian> suggesting renaming Distribution to Domain. actually, i didn't think you were. >> use of a list of "domains" in which the info was valid/relevant >> (ie. "dstc,qld,au,world") *might* achieve what was desired, but >> it's not clear if there was an hierarchical containment implicit >> in the values from "local" to "world". Julian> this is the same is Distribution. Domain was suggested as a Julian> "producer" attribute. and would contain eg "DSTC", "Monash", Julian> etc. thus domain.group provides hierarchical naming scheme, Julian> albeit virutal. and only three levels (universal, domain, group) whereas i was assuming that Bill's proposal encompassed more than that. this would share with "Distribution" the fact that it was a list of values specified by the producer. it is different in that the values are not relative, and therefore retain meaning wherever the traffic is distributed. i'd also note that this differs little from the current use of the "classified" tag in sticker, and the similar feature in eTiks. d From mjh at dstc.edu.au Mon Sep 17 17:09:32 2001 From: mjh at dstc.edu.au (Michael Henderson) Date: Tue Oct 14 08:01:38 2003 Subject: Ticker2001 Minutes and Slides Message-ID: Thanks to everybody who attended last week's tickertape workshop. Slides and minutes from the event are now on the web: http://elvin.dstc.edu.au/ticker2001/ Please mail with any additions or updates.. cheers michael From melfyn at dstc.edu.au Tue Sep 18 09:58:37 2001 From: melfyn at dstc.edu.au (Melfyn Lloyd) Date: Tue Oct 14 08:01:38 2003 Subject: Ticker2001 Minutes and Slides Message-ID: <7AC29F67E4FED311891E009027D5F7B4A2B943@hqmail.dstc.edu.au> Dear All A very successful Ticker/Elvin Workshop was held last week - involving many of DSTC researchers and technical staff from a number of the participants. Congratulations to all involved. Minutes from the Workshop together with slides from the presentations are available via: http://elvin.dstc.edu.au/ticker2001/ Regards - Melv. +----------------------------------+---------------------------------------- + | Melfyn Lloyd | Research Director | | Level 7, GP South Building (78) | Distributed Systems Technology CRC | | Staff House Road | Tel : +61 7 3365 4310 | | The University of Queensland | Fax : +61 7 3365 4311 | | Queensland 4072 | Email : melfyn.lloyd@dstc.edu.au | | Australia | WWW : http://www.dstc.edu.au | | | DSTC is the Australian W3C Office | +----------------------------------+---------------------------------------- + From Martin.Wanicki at Australia.Boeing.com Wed Sep 19 11:45:23 2001 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:38 2003 Subject: Keys Message-ID: <21BEC9503B89D111A8F700805FE6A36909E7E471@xch-bne-01.bal.bna.boeing.com> Dear all, Thinking about the issue of keys and providing them in or out of band, I'm wondering if some additional meta-data about the key might be useful. ie - Key created on Key expires on and possibly others ?? Thoughts ??? Cheers Martin From Matthew.Phillips at dsto.defence.gov.au Mon Sep 24 11:40:19 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:38 2003 Subject: Elvin presence spec draft - request for comments Message-ID: <2149A0BABC77D311AF890090274E00B203A1EAEA@salex005.dsto.defence.gov.au> Hello all, firstly, I'd like to extend thanks to all the participants of the ticker workshop for a very stimulating and enjoyable couple of days. Secondly, as promised, I've developed a draft Elvin presence protocol specification (attached). It extends the original spec (as implemented in Sticker) with your suggestions and a few other ideas I've had along the way. The fields have all been renamed to be more in line with the conventions used in the proposed Ticker 3.0 spec (so I don't get accused of promoting ugliness ;), so it's not directly compatible with Sticker. When the spec is complete, I will produce an application-independent reference implementation in the form of a set of Java components and a test application built from them. Please forward any suggestions or comments out to me (and probably the rest of the list too) and I'll integrate them into a 0.2 revision. Cheers, Matthew. -- matthew.phillips@dsto.defence.gov.au <> Title: Elvin Presence Protocol Elvin Presence Protocol Matthew Phillips Draft 0.1 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 24/09/2001)   1         Purpose The purpose of the presence protocol is to provide a simple and flexible means for Elvin users to communicate their presence online and publish information they may wish to have known about themselves. 2         Requirements Presence services are already provided to a greater or lesser extent by a number of applications, including ‘finger’, CoffeeBiff and various instant messaging clients.  The primary reasons for, and advantages of, providing presence information via the Elvin presence protocol are:

·        Does not require centralised, persistent state.

·        Simple and easy to support.

·        Separate, but complementary to, ticker messaging.

·        Easily extensible. 3         Specification This section describes the protocol, including the operations between clients and the format of the presence notifications. 3.1        Usernames and Domains The presence protocol assumes that users are identified by a combination of username and domain, both of which are case-insensitive strings containing any character except ‘@’ and ‘*’.  The combination of user@domain forms a unique name for the user in ‘presence space’ in the same manner as an email address. A domain is a namespace for grouping logically co-located users, similar purpose to a DNS domain.  It is assumed that all users within the a domain will want to be aware of each other’s presence by default, and that presence info for users outside the domain will be manually added as needed (eg a client might allow a user in another domain to be explicitly added to a ‘buddy list’). As well as providing a namespace framework, the domain concept is the key to scalability of the presence protocol by making it ‘safe’ for clients to, by default, subscribe to all presence info in a domain, knowing this won’t bog down the entire online world. 3.2        Operation The presence protocol operates by exchanging two types of notifications:

·        Presence-Info, and

·        Presence-Request Clients use Presence-Info notifications to publish presence information about themselves, and use Presence-Request to trigger other clients to generate info notifications. Clients subscribe to Presence-Request notifications, and generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up and when any of the presence information previously published has changed.  A number of fields in Presence-Info are optional, meaning they may be left out when their values are the same as they were in the last full notification. 3.3        Example Exchange Note: see sections 3.4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000 & 3.5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000 for definitions of the Presence-Request and Presence-Info notifications. Scenario: Zaphod (in domain “hitch-hikers”) is already online.  Frodo, in the same domain as Zaphod, starts up a presence-capable client. Frodo initially announces he is online with the following full presence info notification:

    Presence-Info: initial Presence-Protocol: 1000              User: Frodo            Domain: hitch-hikers       Status-Text: Online   Status-Duration: 0       Chat-Groups: Chat;ticker-dev       News-Groups: BreakingStories;Slashdot     Ticker-Client: frodoticker 1.0 Zaphod’s client, being subscribed to presence info in that domain, receives the information about Frodo and updates its registry. Frodo’s client now populates its registry by:

1.      Subscribing to presence information for the “hitch-hikers” domain using the expression: require (Presence-Info) && Domain == “hitch-hikers”

2.      Sending a request for presence information about people in the current domain.  The presence request notification Frodo sends is:  Presence-Request: cafebabe12345 Presence-Protocol: 1000            Domain: hitch-hikers              User: * All clients in the domain, including Zaphod’s, receive the request since they have subscribed using an expression like: require (Presence-Request) &&   Domain == “hitch-hikers” &&   (User == “Zaphod” || User == “*”) Zaphod’s client responds with a full presence info notification tagged with the request ID from Frodo’s message:

    Presence-Info: reply cafebabe12345 Presence-Protocol: 1000              User: Zaphod            Domain: hitch-hikers       Status-Text: Online   Status-Duration: 42       Chat-Groups: Chat;ticker-dev       News-Groups: BreakingStories;Slashdot     Ticker-Client: zticker 3.0 x-Number-Of-Heads: 2 Frodo’s client updates its registry, at which point Zaphod, Frodo, and any other interested clients are in sync. Later, when Zaphod decides to go for coffee, he hits the “Coffee!” button on his client, which sends this partial presence notification:     Presence-Info: update Presence-Protocol: 1000              User: Zaphod            Domain: hitch-hikers       Status-Text: Coffee!   Status-Duration: 0
3.4        Presence Request Fields
Field Type Description Possible values When Used Presence-Request String Marks the notification as a presence request and carries a request ID. A random, unique request ID, not longer than 255 characters, no spaces. Always Presence-Protocol Int32 Same as Presence-Info   Always Domain String Same as Presence-Info   Always User String Allows a client to request status info of a particular user (perhaps in another domain) without generating redundant Presence-Info’s from other clients in the domain.  Clients should respond to requests when the “User” field matches their username, or equals “*”. A specific username or “*” (any user).  Always   3.5        Presence Info Fields
Field Type Description Possible values When Used Presence-Info String Marks this as a presence info notification and specifies its subtype

·        “initial”: Full info, with all fields that the client supports populated.  Generated when the client starts and broadcasts initial presence info.

·        “reply  request_id”: Full info (all fields that the client supports are populated) in response to a Presence-Request with ID request_id.

·        “update”: Partial info, with only the optional fields that have changed since last update included.  Generated when presence data (eg Status-Text) changes.

Always Presence-Protocol Int32 The version of the presence protocol that is used in this notification.  major_version * 1000 + minor_version.  Eg. 2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for major/minor versions apply: major version number changes indicate incompatible changes to the protocol, minor number increments indicate backward-compatible changes to the protocol. Always User String The user’s name. Any string: eg “mpp”, “fred”, etc. Always Domain String The user’s domain. Any string: “dsto”, “dstc”, etc. Always Status-Text String The status of the user. Any string, with the following conventional meanings (case insensitive):

·        Starts with “Online”: the user is online.

·        Starts with “Offline”: the user is not currently connected.  This is usually sent as the status when a presence client disconnects.

·        Starts with “Unavailable”: the user is not currently viewing messages (eg away from desk).  Clients that auto-set this status based on activity (keystroke/mouse) monitoring should add a question mark to indicate this is an educated guess (eg “Unavailable?”).

·        Contains “Coffee”: the user is on a coffee break.

Optional Status-Duration Int32 The amount of time (in seconds) that the current status has been in effect. Any integer >= 0.  Undefined behaviour if anyone holds the same status longer than 136 years ;) (232 seconds) Optional: required when Status-Text field is present Chat-Groups String Semicolon-separated list of chat groups the user is subscribed to. Eg. “Chat;ticker-dev” Optional News-Groups String Semicolon-separated list of news groups the user is subscribed to. Eg. “BreakingStories;Slashdot” Optional Ticker-Client String The ticker client the user is running A ticker client name and version eg “sticker 2.0.1”, “xtickertape 2.0a”.  A missing value indicates the user is not running a ticker client.  Users that are running ticker that don’t wish the type of client to be known should use “generic”. Optional
3.6        Notes Presence-Info: the values of this field have been designed so that clients can easily discern the derivation of updates if they wish (for efficiency or otherwise).  However, clients are not required to distinguish between the different types of Status-Info notification: simply updating a registry with the new data in any Presence-Info notification is sufficient, so long as missing optional fields are handled. Note that one possible efficiency enabled by this approach is the ability to opt out of redundant “reply” updates in response to a Presence-Request from other clients, using the expression Status-Info != “reply”.  The other obvious way to mark replies to status requests -- with a separate “In-Reply-To” field -- makes this difficult, since !require (In-Reply-To) can’t be used to create the same effect due to the tri-state logic used in the Elvin subscription language. Presence-Protocol: this is designed so that clients can subscribe to known protocol sets eg “Protocol-Version >= 1000 && Protocol-Version < 3000” picks up any 1.x or 2.x protocol notifications. It is assumed that, if the user is running a ticker client, then they are subscribed to their ‘personal’ chat group named “user@domain”.  This convention makes it obvious how to send a ticker message to someone visible via the presence system. Non-standard fields should use the “x-” naming convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to display the non-standard fields. From phelps at dstc.edu.au Mon Sep 24 20:10:27 2001 From: phelps at dstc.edu.au (Ted Phelps) Date: Tue Oct 14 08:01:38 2003 Subject: Replacement? Supersedes? Something else? Message-ID: <200109241009.f8OA9YH03546@dstc.edu.au> 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 From philc at csee.uq.edu.au Mon Sep 24 20:25:10 2001 From: philc at csee.uq.edu.au (Phil Cook) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Replacement? Supersedes? Something else? In-Reply-To: <200109241009.f8OA9YH03546@dstc.edu.au> Message-ID: <01092420251700.12251@morgan> On Monday 24 September 2001 20:09, Ted Phelps wrote: > 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. This certainly is an elegant approach (I think it did come up at the w/shop, but I can't recall the outcome). Could it lead to problems with existing clients that assume Message-Ids are unique? KTickertape and XTickertape (as far as I recall) wouldn't be too worried about this (though they would have to be modified to get the intended semantics right of course), but I don't know the internals of any other clients well enough to know if they'd have trouble with it or not. I'm still concerned, however, by the potential for malicious use. The idea of using this scheme for fixing typos seems neat at first, but I'm not convinced of its necessity, or even desirability. Typos have become part of tickertape culture. People expect and tolerate them, and they can even be sources of amusement (jokes based on sed will never get old!). More importantly, however, I think the scheme is potentially confusing because it could seriously break the user's very simple mental model of tickertape interaction (temporal effects come to mind). Furthermore, it is unclear exactly how non-scrolling clients should implement the scheme, whereas Replacement can be safely ignored by such clients. Phil. _____________________________________________________________________________ Phil Cook "No Neil, after you" Ph.D. student at large - Buzz Aldrin School of Computer Science & Electrical Engineering The University of Queensland, QLD, 4072, Australia From kas-list at magnetic-ink.dk Thu Sep 27 01:05:43 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:38 2003 Subject: Elvin presence spec draft - request for comments Message-ID: <20010926170548.A6555@magnetic-ink.dk> G'day mates, With keen interest I've been flipping through Matthew Phillips' neat PowerPoint slides, "Awareness in Tickerland", from the Ticker2001 workshop. I've also been snooping a bit on Sticker 2's ELVIN_ONLINE_STATUS* emissions and was just about to implement something similar in my roll-your-own tickertape client written in python when I stumbled upon the Elvin Presence RFC on the web. I assume that the ELVIN_ONLINE_STATUS_REQUEST from the slides equals the Presence-Request from the RFC, and that the ELVIN_ONLINE_STATUS corresponds to the Presence-Info -- in spirit, not in word -- and I have a question about the implementation. The way I read it -- and feel free to correct me -- the presence protocol would not be very useful for me the way Tickerland looks these days: there's a bunch of guys (and a few gals) Down Under, and then there's me and my shadow at the other end of the world. When I start my ticker client it is interesting for me to know who's online in Australia since they are my only company in Tickerland (oh, the other day a Danish company, probably mistakenly, popped up on my tickertape and said something about a fax or a printer, but I haven't seen them since...). Now, Sticker2 seems to make two subscriptions [for me] on startup: 
require(ELVIN_ONLINE_STATUS) && DOMAIN == "zigzag" && USER != "kas"
require(ELVIN_ONLINE_STATUS_REQUEST) && DOMAIN == "zigzag"
i.e., it asks for presence info from anybody in my own domain, and since I'm the only one in my domain who uses Elvin messaging (well, probably in Denmark, or even the entire Europe) there will never be any answers to the status requests, will there? :-( I suppose I could make a different implementation in my own ticker client, but I still see it as a problem -- and now I'm getting to the point -- that the proposed presence protocol is domain focused. I am usually elvining as kas@zigzag. Then there's j@laptop (or @lerkim or @monash, or whatever). And d@monash, etc., etc. How, and where, am I gonna catch those boys if my client only wants to subscribe to presence info from my own lonesome domain? Perhaps it's beyond the scope of the presence protocol, and so perhaps I should rather be using ICQ for this, but when I start up my ticker I would like to be able to see who's online "globally" -- that e.g. Julian, Bill, David and Martin are online Down Under, even if they're on separate domains, doing different things. I admit that if Elvin ever gets as accepted worldwide as ICQ is now, then we'll end up with an amazing buddy list, but I am looking at the situation and my requirements here and now. Assuming clients are ~/.ticker/ aware, would it make sense to have, e.g., a ~/.ticker/buddies file, perhaps along the lines of 
# Name		Usually seen as
Julian		j@(laptop|lerkim|monash)
Christopher	cmlp@(dstc|home)
# eof
and then have your client make specific presence requests for all user@domain entities mentioned in that file? Or is there a more efficient way to accomplish what I want? Or have I misunderstood the whole thing? Cheers, // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From bill at dstc.edu.au Thu Sep 27 01:43:25 2001 From: bill at dstc.edu.au (Bill Segall) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <20010926170548.A6555@magnetic-ink.dk> Message-ID: <200109261543.f8QFhPa02868@piglet.dstc.edu.au> Yes! Right now we're using our "user" name in a local setting to indicate where we are and half the information content is only applicable in the local setting. Worse still the "name" half is only locally unique. We really need to separate somehow the idea of "name": (our simple local label), identity (uniqueness), and locality ... and others?. "name" seems to be a display thing. identity could be what you look for in a buddy list, while locality is really part of the awareness atributes. Locality is probably important as display information depending on context (perhaps where co-located people really care?). It's difficult to keep the interfaces simple and maintain separation for these but I think Klaus is already demonstrating a lack of scalablity in what we're currently doing. Buddy lists seem to be what a lot of the mainstream internet chat applications do. I've been assuming IMPP doesn't help us but I've really only looked at the IM and not the PP :-) Is it worth looking at? Has anyone else done this before? Bill. From mwanicki at dstc.edu.au Thu Sep 27 10:09:13 2001 From: mwanicki at dstc.edu.au (Martin@dstc) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <200109261543.f8QFhPa02868@piglet.dstc.edu.au> Message-ID: <003e01c146e8$744c50c0$bcb06682@banyan> I completeley agree with Klaus & Bill on this one. The domain thing may be useful but not on its own Perhaps it should be up to the client to group buddies . eChatz did the buddy list thing by registering a buddy ID so it didnt matter what display name the buddy used. If he or she is online you get to know (unless they've disabled awareness). On startup eChatz would send an online message that caused other clients to respond with their online status, but their name was not really used except for display purposes, what I used instead was an ID that represents that buddy and the client was only interested in the ID, regardless of what the display name happened to be. I see a problem in that not every client in the world should get the PING. only my Buddies should get the PING or the PONG I'm not sure how best to implement this .. does the PONG contain my info - or only the info of the people I'm looking for (pinging) The latter makes the subscription a little less complicated but it means I have to know before hand who I''m interested in. Perhaps the protocol could/should be extended so a client must first request your presence ID ICQ does something like this .. ie "Foo Bar has requested to add you to their buddy list, do you wish to be added to Foo Bar's buddy list ?" This request _could_ be made to whatever display name the client is useing at the time, so if you see a message in ticker and you want to add that person to your buddy list you could send a request that the other party listens to by looking for their display name somewhere in the request notification (do we need a new field for this??) If the response is yes then it should contain my Display Name and my ID, where the ID is constant. Its a given that if I let someone add me to their buddy list that I have the right to add them to mine. Groups/domain may actually become irrelevant and clients could facilitate their own grouping of "Buddies" Over to the experts .... Cheers, Martin From arnold at dstc.monash.edu.au Thu Sep 27 10:41:39 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <200109261543.f8QFhPa02868@piglet.dstc.edu.au> Message-ID: <200109270041.f8R0fhi16864@xevious.dstc.monash.edu.au> -->"Bill" == Bill Segall writes: Bill> Has anyone else done this before? only about 10 different groups ;-) the usual approaches have been: 1) add access control and authentication to the presence information, and manage the visibility (including proxying and forwarding) of your presence notifications explicitly. 2) encode a social policy implicitly in the protocol, typically limiting visibility of presence to your "buddy list" with little support for groups (or domains, as Sticker calls them). i've yet to look at Matthew's proposal, so excuse me if you've done this, but ... there's been a *lot* of work in this area over the last 5 years, and we'd do well not to reinvent the wheel, imo. good starting points would be - the IETF IMPP working group. http://www.ietf.org/ids.by.wg/impp.html http://www.ietf.org/html.charters/impp-charter.html - the IETF PRIM working group. http://www.imppwg.org http://www.ietf.org/html.charters/prim-charter.html - the IETF SIMPLE working group. http://www.ietf.org/html.charters/simple-charter.html http://mailman.dynamicsoft.com/pipermail/simple - Jabber. http://www.jabber.org http://www.jabber.com http://www.jabbercentral.org - ICQ Protocol http://www.d.kth.se/~d95-mih/icq/ useful papers would come from ECSCW, CSCW, CHI, AUSCHI, etc. i'll have a look at Matthew's RFC ASAP. d From Matthew.Phillips at dsto.defence.gov.au Fri Sep 28 11:41:23 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments Message-ID: <2149A0BABC77D311AF890090274E00B203A1EAF2@salex005.dsto.defence.gov.au> Hi all, This is a kind of consolidated reply to Klaus, Bill, Martin and David's comments. Klaus: your interpretation of how the RFC relates to Sticker's implementation is spot on. All: I guess I'm actually proposing a spec-within-a-spec for the presence RFC, namely that we adopt a unique user naming scheme for ticker similar to email, where local usernames are resolved using logical domains. Right now, people are using "name@machine-name", "person@home", "person@dstc", etc as de-facto names, mainly to communicate not only who they are, but where they are at the moment. This can be confusing, not least of all because I need to know that bill@home and bill@dstc are the same person, but (probably) bill@large is not. So what I'm suggesting is that we formalise the thing: pick a domain that suits you best and stick with it. Other than its role as a username resolution device, the domain can be whatever you like (although using your organisation or DNS domain would be logical). As Bill suggests, other information, such as where you are, can go into the presence info. I really, really want to avoid having a binary crud unique 'user id'. The other reason a domain is useful is that it gives you a useful starting buddy list that is automatically populated and maintained (note that being able to see everyone in the whole of tickerland is unscalable). When you (inevitably) want to add people outside your domain to your buddy list, your client should make it easy to do this. So Klaus, you've hit a problem in the Sticker UI, not in the spec - you can't see the people you want to because you can't add them to your buddy list. A way of querying what domains there are are would be good too, but I suspect this would probably require a central server that is subscribed to all Presence-Request's. I'll have another look at IMPP and Jabber to see if there is any wisdom to be found there. Cheers, Matthew. > -----Original Message----- > From: kas-list@magnetic-ink.dk [mailto:kas-list@magnetic-ink.dk] > Sent: Thursday, 27 September 2001 12:36 AM > To: Tickertape Development > Subject: [ticker-dev] Re: Elvin presence spec draft - request for > comments > > > G'day mates, > > With keen interest I've been flipping through Matthew Phillips' neat > PowerPoint slides, "Awareness in Tickerland", from the Ticker2001 > workshop. > > I've also been snooping a bit on Sticker 2's ELVIN_ONLINE_STATUS* > emissions and was just about to implement something similar in my > roll-your-own tickertape client written in python when I stumbled > upon the Elvin Presence RFC on the web. > > I assume that the ELVIN_ONLINE_STATUS_REQUEST from the slides equals > the Presence-Request from the RFC, and that the ELVIN_ONLINE_STATUS > corresponds to the Presence-Info -- in spirit, not in word -- and I > have a question about the implementation. > > The way I read it -- and feel free to correct me -- the presence > protocol would not be very useful for me the way Tickerland looks > these days: there's a bunch of guys (and a few gals) Down Under, and > then there's me and my shadow at the other end of the world. When > I start my ticker client it is interesting for me to know who's > online in Australia since they are my only company in Tickerland > (oh, the other day a Danish company, probably mistakenly, popped > up on my tickertape and said something about a fax or a printer, > but I haven't seen them since...). > > Now, Sticker2 seems to make two subscriptions [for me] on startup: > > 
> require(ELVIN_ONLINE_STATUS) && DOMAIN == "zigzag" && USER != "kas"
> require(ELVIN_ONLINE_STATUS_REQUEST) && DOMAIN == "zigzag"
>
> > i.e., it asks for presence info from anybody in my own domain, and > since I'm the only one in my domain who uses Elvin messaging (well, > probably in Denmark, or even the entire Europe) there will never be > any answers to the status requests, will there? :-( > > I suppose I could make a different implementation in my own ticker > client, but I still see it as a problem -- and now I'm getting to > the point -- that the proposed presence protocol is domain focused. > > I am usually elvining as kas@zigzag. Then there's j@laptop (or > @lerkim or @monash, or whatever). And d@monash, etc., etc. How, > and where, am I gonna catch those boys if my client only wants to > subscribe to presence info from my own lonesome domain? > > Perhaps it's beyond the scope of the presence protocol, and so > perhaps I should rather be using ICQ for this, but when I start up > my ticker I would like to be able to see who's online "globally" -- > that e.g. Julian, Bill, David and Martin are online Down Under, > even if they're on separate domains, doing different things. > I admit that if Elvin ever gets as accepted worldwide as ICQ is > now, then we'll end up with an amazing buddy list, but I am > looking at the situation and my requirements here and now. > > Assuming clients are ~/.ticker/ aware, would it make sense to have, > e.g., a ~/.ticker/buddies file, perhaps along the lines of > > 
> # Name		Usually seen as
> Julian		j@(laptop|lerkim|monash)
> Christopher	cmlp@(dstc|home)
> # eof
>
> > and then have your client make specific presence requests for all > user@domain entities mentioned in that file? Or is there a more > efficient way to accomplish what I want? > > Or have I misunderstood the whole thing? > > > Cheers, > > // Klaus > > -- > A man, just one - > also a fly, just one - > in the huge drawing room. > From arnold at dstc.monash.edu.au Fri Sep 28 12:32:41 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EAF2@salex005.dsto.defence.gov.au> Message-ID: <200109280232.f8S2Wui23310@xevious.dstc.monash.edu.au> -->"Matthew" == Phillips, Matthew writes: Matthew> All: I guess I'm actually proposing a spec-within-a-spec Matthew> for the presence RFC, namely that we adopt a unique user Matthew> naming scheme for ticker similar to email, where local Matthew> usernames are resolved using logical domains. i had a late-night, in-bed, semi-conscious read of the draft last night, and this was the point that struck me most. the use of foo@location naming evolved (again, i think Rik Taylor started it, or at least popularised it?) to add an extra dimension to the awareness generated via ticker. you could now, almost implicitly, determine where someone was. i like this a *lot*, but it has always clashed with my desire to enable scalability of ticker to a larger audience, something that simple names don't, and for a while, the use of foo@location competed with foo@some.unique.domain as we attempted to encourage people to adopt a globally useful naming scheme. my guess is that the popularity of foo@location at DSTC is a result of our multi-site groups, frequent use of ticker while travelling and the popularity of working from home. Matthew> As Bill suggests, other information, such as where you are, Matthew> can go into the presence info. yes. and, no. putting location info into a/the presence protocol is good, and right. but i don't think a result where you need to have a presence client to determine this is necessarily good. i *like* the fact that tickertape is currently able to give me location information as a side-benefit. perhaps this comes back to the idea of tickertape events having both a unique name for the sender, and a nickname that can be displayed? i don't think (?) i would like to require support for the presence protocol in all tickertape clients? Matthew> I really, really want to avoid having a binary crud unique Matthew> 'user id'. agreed. i think most of the presence systems have decided that an email address is the best solution, since everyone has one already, and it's already unique, and it's human-readable, textual and all that nice stuff. Matthew> The other reason a domain is useful is that it gives you a Matthew> useful starting buddy list that is automatically populated Matthew> and maintained (note that being able to see everyone in the Matthew> whole of tickerland is unscalable). i do like the idea of have my presence client have a default domain, but i'm not sure it needs to be the domain part of my unique name. for example, i would likely want to use `d@0x1.org' as my unique name because i have a network life outside my employer (well, kinda) and because it is persistent across changes in employer. but i would normally want to have `dstc.edu.au' or maybe 'dstc.monash.edu.au' as my default domain (given that i'm the only person in the 0x1.org domain ;-) i know this is mkaing things more complex. i think that defaulting to using the domain suffix of the user's name as their presence domain is sensible. perhaps we need to consider a generic concept of groups, rather than domains? this could work similarly to awareness of tickertape channel subscriptions? Matthew> I'll have another look at IMPP and Jabber to see if there Matthew> is any wisdom to be found there. perhaps the best place to start is the IMPP requirements RFC? http://www.ietf.org/rfc/rfc2779.txt d From mwanicki at dstc.edu.au Fri Sep 28 14:45:37 2001 From: mwanicki at dstc.edu.au (Martin@dstc) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <200109280232.f8S2Wui23310@xevious.dstc.monash.edu.au> Message-ID: <00a201c147d8$3d0106b0$bcb06682@banyan> Why cant the clients organise the people they are interested in into their own domain groups. Automagic is cool but there seems to be no "consitantly reliable" way to determin that an individual is in the same domain as our client (us). Especially when we seem to be abstracting domain to mean a "group" / "team" / "bunch of people we are interested in" Take the fact that sometimes i work at DSTC and sometimes from home and sometimes at my head office I change my username/domain to reflect where I am but my work buddies are only interested in me and could care less about my domain - except that it gives them some further clue as to what I'm up to. Where I am (domain wise) shouldnt automagically restrict the distrubution of my awareness state. If a client just see's the name part and stores it in a grouping of 'People I want aware of my activities' and if I get an awareness message from someone not in that list I can (optionally) add them to the list. I need only look for awareness messages that have my name in them, if the sender of the notif isnt in my list I can choose to add them, thereby beginning to notify them of my awareness states. I only have to send awareness messages containing the list of people I want to send awareness stuff to. The uniqueness of the name is the only problem I can see with this method, thats why I had a unique name for each individual which was just like a message_id. If thats so undesirable there should be other ways. Although the idea was a little unfriendly - In eChats I wouldnt let the client log on and emit their username if that username was already in use, you had to choose another name thats not a real problem either, cause the name only has to be unique in the list of 'People I want aware of my activities' All this being said I havent yet had time to wade through some of the other protocols, so probably deserve a spanking for piping up yet again:-) Martin From kas-list at magnetic-ink.dk Fri Sep 28 15:22:13 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence spec draft - request for comments In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EAF2@salex005.dsto.defence.gov.au> Message-ID: <20010928072221.A13817@magnetic-ink.dk> David Arnold wrote: > perhaps we need to consider a generic concept of groups, rather > than domains? I vote for that one -- _and_ the user@domain naming scheme. Using the ELVIN_ONLINE_STATUS* as an example, what if we add another field called GROUPS that contains a semicolon separated (to keep the semantics of {CHAT,NEWS}_GROUPS) list of contact groups that the user is a member of? Initially GROUPS would only contain one group, namely the user's own domain, but he could then expand the list by becoming a member of already established groups or he could create his own group. (I'm still scratching my own itch.) So instead of doing a ELVIN_ONLINE_STATUS_REQUEST: 1 DOMAIN: "mydomain" request to see what users are online in his own domain, a user would issue a ELVIN_ONLINE_STATUS_REQUEST: 1 DOMAIN: "mydomain" GROUP: "mygroup" request for each of the groups that he is currently a member of. The DOMAIN field is maintained for greater flexibility. Although this scheme doesn't fully solve the problem of global scalability, at least it would allow automagic online awareness across domain boundaries. Anyone? // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From matthew.phillips at dsto.defence.gov.au Fri Sep 28 21:06:51 2001 From: matthew.phillips at dsto.defence.gov.au (Matthew Phillips) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <200109280232.f8S2Wui23310@xevious.dstc.monash.edu.au> Message-ID: <002901c1480c$d1ac1e10$102db983@dsto.defence.gov.au> Another consolidated reply to David, Martin and Klaus. David: > i had a late-night, in-bed, semi-conscious read of the draft last > night, and this was the point that struck me most. Good, because I wrote it early morning, semi-conscious, so we're nicely balanced ;) > the use of foo@location naming evolved (again, i think Rik Taylor > started it, or at least popularised it?) to add an extra dimension to > the awareness generated via ticker. you could now, almost implicitly, > determine where someone was. > i like this a *lot*, but it has always clashed with my desire to > enable scalability of ticker to a larger audience, something that > simple names don't, and for a while, the use of foo@location competed > with foo@some.unique.domain as we attempted to encourage people to > adopt a globally useful naming scheme. > > my guess is that the popularity of foo@location at DSTC is a result of > our multi-site groups, frequent use of ticker while travelling and the > popularity of working from home. The problem of course is that we are overloading someone's identify (static) with location (variable). In fact, this whole debate is tricky, because we want a way of uniquely identifying people using some text that is based on their attributes rather than a random string. And there isn't one. The usual workaround is to say the combination of my name plus my organisation/group/collective/borg is fairly unique, so I'll use that. But most of us wear at least 2 hats: work and personal, so we have two identities. Which isn't necessarily a bad thing - maybe we don't want everyone to be aware that they are the same person. So, upshot is: a username/logical domain combo actually seems to work. > Matthew> As Bill suggests, other information, such as where you are, > Matthew> can go into the presence info. > > yes. and, no. > > putting location info into a/the presence protocol is good, and right. > > but i don't think a result where you need to have a presence client to > determine this is necessarily good. i *like* the fact that tickertape > is currently able to give me location information as a side-benefit. > > perhaps this comes back to the idea of tickertape events having both a > unique name for the sender, and a nickname that can be displayed? > > i don't think (?) i would like to require support for the presence > protocol in all tickertape clients? Yep, I agree we shouldn't require presence support for using ticker effectively, and I think that a "Display-Name" or somesuch field on ticker could be used to replace what would be lost by using a domain-as-identity scheme. I could have username 'Matthew@dsto' with a display name of "Matthew (at home)" or somesuch. > Matthew> I really, really want to avoid having a binary crud unique > Matthew> 'user id'. > > agreed. i think most of the presence systems have decided that an > email address is the best solution, since everyone has one already, > and it's already unique, and it's human-readable, textual and all that > nice stuff. > > Matthew> The other reason a domain is useful is that it gives you a > Matthew> useful starting buddy list that is automatically populated > Matthew> and maintained (note that being able to see everyone in the > Matthew> whole of tickerland is unscalable). > > i do like the idea of have my presence client have a default domain, > but i'm not sure it needs to be the domain part of my unique name. > > for example, i would likely want to use `d@0x1.org' as my unique name > because i have a network life outside my employer (well, kinda) and > because it is persistent across changes in employer. > > but i would normally want to have `dstc.edu.au' or maybe > 'dstc.monash.edu.au' as my default domain (given that i'm the only > person in the 0x1.org domain ;-) Your comments and Klaus's make a convincing case that presence clients should _start_ by defaulting to subscribing only to your domain for simplicity, but that other domains should be able to be added as needed. This lets you move domains but still maintain presence contact. So, when you are at home as d@0x1.org, you might also subscribe to the 'elvin.dstc' domain. I'm viewing domains as sort of 'public buddy lists' - I want to see everyone who's online at DSTO and I don't know who they are (now, or in the future) so I subscribe that domain. In fact, if 'group' wasn't already used for referring to ticker groups, I would have used that rather than domain, since it's more in keeping with its function. Martin: > Why cant the clients organise the people they are interested in into their > own domain groups. > Automagic is cool but there seems to be no "consitantly reliable" way to > determin that an individual > is in the same domain as our client (us). > Especially when we seem to be abstracting domain to mean a "group" / "team" > / "bunch of people we are interested in" Without a domain concept everyone _has_ to build a static buddy list before the presence protocol is useful, and people have no way of automatically announcing that they are now 'out there' to a likely domain of interest. I've seen the value of this a number of times at DSTO: when someone experiments with Sticker they immediately see who's already there and some groups they're listening to. Without that presence, they would start up Sticker, fire a message to Chat where it gets buried, after which they never bother running it again. Note that you guys are a serious worst-case scenario ;) You all use ticker from various locations wearing various hats. A ticker newbie probably wants to enter a username/domain and automagically have everything else kick in. Later, they can start messing with adding people/domains to the buddy list, but this gives a low-overhead, useful starting point. In summary, I would still push for people to be in one domain, but to have optional visiblilty of (and visibility in) other domains. Sorry to rabbit on, I would have written a shorter response, but I didn't have time, Cheers, Matthew. From arnold at dstc.monash.edu.au Fri Sep 28 22:32:07 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Re: Elvin presence spec draft - request for comments In-Reply-To: <002901c1480c$d1ac1e10$102db983@dsto.defence.gov.au> Message-ID: <200109281232.f8SCWNi25367@xevious.dstc.monash.edu.au> -->"Matthew" == Matthew Phillips writes: Matthew> Good, because I wrote it early morning, semi-conscious, so Matthew> we're nicely balanced ;) ;-) Matthew> The problem of course is that we are overloading someone's Matthew> identify (static) with location (variable). exactly. Matthew> In fact, this whole debate is tricky, because we want a way Matthew> of uniquely identifying people using some text that is Matthew> based on their attributes rather than a random string. and not everyone is prepared to maintain their own domain in order to get this ;-) Matthew> So, upshot is: a username/logical domain combo actually Matthew> seems to work. agreed. Matthew> Yep, I agree we shouldn't require presence support for Matthew> using ticker effectively, and I think that a "Display-Name" Matthew> or somesuch field on ticker could be used to replace what Matthew> would be lost by using a domain-as-identity scheme. I Matthew> could have username 'Matthew@dsto' with a display name of Matthew> "Matthew (at home)" or somesuch. this at least makes identity a distinct field, while leaving the semantics of "Matthew (at home)" a little murky/flexible ;-) julian? any suggestions for ontologically-correct naming here? i'd really like to publish the ticker-3.0 draft protocol ASAP ... Matthew> I'm viewing domains as sort of 'public buddy lists' - I Matthew> want to see everyone who's online at DSTO and I don't know Matthew> who they are (now, or in the future) so I subscribe that Matthew> domain. me too. i like that level of abstraction. Matthew> In fact, if 'group' wasn't already used for referring to Matthew> ticker groups, I would have used that rather than domain, Matthew> since it's more in keeping with its function. well -- while we all agreed on "group" for ticker, "channel" is still possible. perhaps it's worth using "channel" in ticker to support this distinction? i think i prefer "group" over "domain" enough to move from "group" to "channel" for ticker. maybe? what other words might work to describe a collection of "buddy"s (i fear that word is entrenched now) ? i had a chat to Louise and we came up with (in no particular order or recommendation): clan, tribe, gang, posse, pack, team others? anyone? Matthew> Note that you guys are a serious worst-case scenario ;) always ;-) Matthew> A ticker newbie probably wants to enter a username/domain Matthew> and automagically have everything else kick in. Later, they Matthew> can start messing with adding people/domains to the buddy Matthew> list, but this gives a low-overhead, useful starting point. i defintely agree. something automatic is really important. Matthew> In summary, I would still push for people to be in one Matthew> domain, but to have optional visiblilty of (and visibility Matthew> in) other domains. i think that's reasonable. d From ilister at dstc.edu.au Tue Oct 2 10:51:01 2001 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:38 2003 Subject: ticker-dev Tickertape group Message-ID: Hi, There is now a `ticker-dev' Tickertape group for interactive technical talk about Tickertape and its development. The group is available on DSTC's public Elvin server at elvin://elvin.dstc.edu.au, and is federated to all sites with DSTC. Please feel free to federate it to your own organisation as well. Ian From Matthew.Phillips at dsto.defence.gov.au Thu Oct 4 19:52:31 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:38 2003 Subject: Elvin presence specification draft 0.2 Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB0B@salex005.dsto.defence.gov.au> Hello all, as noted in a recent ticker conversation, I've been converted to the idea of supporting multiple presence groups and keeping the user@domain concept seperate. I've also renamed the term "domain" to "group". Attached is a revised draft spec for comment. I haven't had any non domain-related feedback on the previous one, and I hope this is a sign of general consent rather than utter boredom. Cheers, Matthew. Title: Elvin Presence Protocol Elvin Presence Protocol Matthew Phillips Draft 0.2 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 4/10/2001)   Contents  TOC \o "2-2" \h \z \t "Heading 1,1" 1          Aim.. PAGEREF _Toc526853755 \h 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700350035000000 2            Requirements  PAGEREF _Toc526853756 \h 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700350036000000 3            Specification  PAGEREF _Toc526853757 \h 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700350037000000 3.1                  User Identity  PAGEREF _Toc526853758 \h 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700350038000000 3.2                  Groups  PAGEREF _Toc526853759 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700350039000000 3.3                  Operation  PAGEREF _Toc526853760 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360030000000 3.4                  Example Exchange. PAGEREF _Toc526853761 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360031000000 3.5                  Presence Request Fields  PAGEREF _Toc526853762 \h 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360032000000 3.6                  Presence Info Fields  PAGEREF _Toc526853763 \h 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360033000000 3.7                  Notes  PAGEREF _Toc526853764 \h 8 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360034000000 4            References  PAGEREF _Toc526853765 \h 8 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360035000000 4.1                  Other Presence Protocols  PAGEREF _Toc526853766 \h 8 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320036003800350033003700360036000000   1         Aim The aim of the presence protocol is to provide a simple and flexible means for Elvin users to communicate their presence online and publish information they may wish to have known about themselves. 2         Requirements Presence services are already provided to a greater or lesser extent by a number of applications, including ‘finger’, CoffeeBiff and various Instant Messaging (IM) clients such as Jabber and ICQ.  The primary reasons for, and advantages of, providing presence information via the Elvin presence protocol are:

·        Does not require centralised, persistent state.

·        Simple and thus easy to support.

·        Separate, but complementary to, ticker messaging.

·        Extensible. 3         Specification This section describes the protocol, including the operations between clients and the format of the presence notifications. 3.1        User Identity The presence protocol assumes that users are identified by a combination of name and domain, both of which are case-insensitive strings containing any character except ‘@’.  The combination of name@domain forms a unique user ID for the user in ‘presence space’ in the same manner as an email address. 3.2        Groups A group is a namespace containing a set of online users.  Every online user will be in at least one group and may opt to be in several.  All users within a group will be aware of each other’s presence by default.  A group can be thought of as a public, dynamic ‘buddy list’ that is automatically populated with community of people.  When users want to add people outside their main group to their buddy list, they have two options: explicitly add the other user by name, or join the other group. For example, suppose all the people working in the Frob Testing Division of Bob’s Frobs Inc, may elect to be in the ‘ftc.bobco’ group.   The manager of FTC might also elect to be in the ‘management.bobco’ group so they can maintain contact with the managers of other divisions. As well as providing a way to partition presence information into communities, the group concept is the key to scalability of the presence protocol by making it efficient for clients to subscribe to all presence info in a group, knowing this won’t bog down the entire online world. 3.3        Operation The presence protocol operates by exchanging two types of notifications:

·        Presence-Info, and

·        Presence-Request Clients use Presence-Info notifications to publish presence information about themselves, and use Presence-Request to trigger other clients to generate info notifications. Clients subscribe to Presence-Request notifications, and generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up and when any of the presence information previously published has changed.  A number of fields in Presence-Info are optional, meaning they may be left out when their values are the same as they were in the last full notification. 3.4        Example Exchange Note: see sections 3.5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000 & 3.6 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000 for definitions of the Presence-Request and Presence-Info notifications. Scenario: Zaphod@hitch-hikers is already online.  Frodo@hitch-hikers, starts up a presence-capable client.  Both are in the ‘hitch-hikers’ group. Frodo initially announces he is online with the following full presence info notification:

    Presence-Info: initial Presence-Protocol: 1000              User: Frodo@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Online   Status-Duration: 0       Chat-Groups: |Chat|ticker-dev|       News-Groups: |BreakingStories|Slashdot|     Ticker-Client: frodoticker 1.0 Zaphod’s client, being subscribed to presence info in for the hitch-hikers group, receives the information about Frodo and updates its registry. Frodo’s client now populates its registry by:

1.      Subscribing to presence information for the hitch-hikers group using the expression: require(Presence-Info) && contains(Groups, “|hitch-hikers|”)

2.      Sending a request for presence information about people in the current group.  The presence request notification Frodo sends is:  Presence-Request: cafebabe12345 Presence-Protocol: 1000            Groups: |hitch-hikers|              User: * All clients in the group, including Zaphod’s, receive the request since they have subscribed using an expression like: require(Presence-Request) &&   contains(Groups, “|hitch-hikers|”) &&   (User == “Zaphod” || User == “*”) Zaphod’s client responds with a full presence info notification tagged with the request ID from Frodo’s message:

    Presence-Info: reply cafebabe12345 Presence-Protocol: 1000              User: Zaphod@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Online   Status-Duration: 42       Chat-Groups: |Chat|ticker-dev|       News-Groups: |BreakingStories|Slashdot|     Ticker-Client: zticker 3.0 x-Number-Of-Heads: 2 Frodo’s client updates its registry, at which point Zaphod, Frodo, and any other interested clients are in sync. Later, when Zaphod decides to go for coffee, he hits the “Coffee!” button on his client, which sends this partial presence notification:     Presence-Info: update Presence-Protocol: 1000              User: Zaphod@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Coffee!   Status-Duration: 0
3.5        Presence Request Fields
Field Type Description Possible values When Used Presence-Request String Marks the notification as a presence request and carries a request ID. A random, unique request ID, not longer than 255 characters, no spaces. Always Presence-Protocol Int32 Same as Presence-Info   Always Groups String Same as Presence-Info   Always User String Allows a client to request status info of a particular user (perhaps in another group) without generating redundant Presence-Info’s from other clients in the group.  Clients should respond to requests when the “User” field matches their username, or equals “*”. A specific username or “*” (any user).  Always   3.6        Presence Info Fields
Field Type Description Possible values When Used Presence-Info String Marks this as a presence info notification and specifies its subtype

·        “initial”: Full info, with all fields that the client supports populated.  Generated when the client starts and broadcasts initial presence info.

·        “reply  request_id”: Full info (all fields that the client supports are populated) in response to a Presence-Request with ID request_id.

·        “update”: Partial info, with only the optional fields that have changed since last update included.  Generated when presence data (eg Status-Text) changes.

Always Presence-Protocol Int32 The version of the presence protocol that is used in this notification.  major_version * 1000 + minor_version.  Eg. 2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for major/minor versions apply: major version number changes indicate incompatible changes to the protocol, minor number increments indicate backward-compatible changes to the protocol. Always User String The user’s name. Any string: eg “mpp”, “fred”, etc. Always Groups String The groups the user is a member of. A set of group names separated by ‘|’. For example “|dsto|quake heroes|”. Note that the preceding and trailing ‘|’s allow clients to easily use the ‘contains’ function to test for particular groups without having to handle three cases (ie where the group is at the beginning, middle and end of the list). Always Status-Text String The status of the user. Any string, with the following conventional meanings (case insensitive):

·        Starts with “Online”: the user is online.

·        Starts with “Offline”: the user is not currently connected.  This is usually sent as the status when a presence client disconnects.

·        Starts with “Unavailable”: the user is not currently viewing messages (eg away from desk).  Clients that auto-set this status based on activity (keystroke/mouse) monitoring should add a question mark to indicate this is an educated guess (eg “Unavailable?”).

·        Contains “Coffee”: the user is on a coffee break.

Optional Status-Duration Int32 The amount of time (in seconds) that the current status has been in effect. Any integer >= 0.  Undefined behaviour if anyone holds the same status longer than 136 years ;) (232 seconds) Optional: required when Status-Text field is present Chat-Groups String The set of chat groups the user is subscribed to. Eg. “|Chat|ticker-dev|” Optional News-Groups String The set of news groups the user is subscribed to. Eg. “|BreakingStories|Slashdot|” Optional Ticker-Client String The ticker client the user is running A ticker client name and version eg “sticker 2.0.1”, “xtickertape 2.0a”.  A missing value indicates the user is not running a ticker client.  Users that are running ticker that don’t wish the type of client to be known should use “generic”. Optional
3.7        Notes Presence-Info: the values of this field have been designed so that clients can easily discern the derivation of updates if they wish (for efficiency or otherwise).  However, clients are not required to distinguish between the different types of Status-Info notification: simply updating a registry with the new data in any Presence-Info notification is sufficient, so long as missing optional fields are handled. Note that one possible efficiency enabled by this approach is the ability to opt out of redundant “reply” updates in response to a Presence-Request from other clients, using the expression Status-Info != “reply”.  The other obvious way to mark replies to status requests -- with a separate “In-Reply-To” field -- makes this difficult, since !require (In-Reply-To) can’t be used to create the same effect due to the tri-state logic used in the Elvin subscription language. Presence-Protocol: this is designed so that clients can subscribe to known protocol sets eg “Protocol-Version >= 1000 && Protocol-Version < 3000” picks up any 1.x or 2.x protocol notifications. It is assumed that, if the user is running a ticker client, then they are subscribed to their ‘personal’ chat group with the same name as their user ID ie “user@domain”.  This convention makes it obvious how to send a ticker message to someone visible via the presence system. Non-standard fields should use the “x-” naming convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to display the non-standard fields. 4         References Thanks to David Arnold for providing the initial set of links that these references are based on. 4.1        Other Presence Protocols 4.1.1        Simple General Awareness Protocol (SGAP) A Lotus-sponsored IETF Internet Draft, which expired on May 98.  It’s not clear if this is still a live project.  Specification talks mainly about client/server interactions and message formats.  Seems to offer little wisdom for this specification. Also see Lotus Research Page for more information. 4.1.2        Instant Messaging and Presence Protocol (IMPP) Uses presence information messages (MIME type message/cpim) that contain an XML presence info ‘payload’. Example payload (from IMPP internet draft):                          open                     away                      im:shingo@jp.fujitsu.com       I'll be in Tokyo tomorrow                          open              mailto:shingo@jp.fujitsu.com             The main wisdom to be gained here is that the presence info is divided into one or more contact tuples, which describe the users’ status in a particular online medium.  In the example, the user is saying they have both Instant Messaging and email contacts, but are not online for IM.  The addition of the note to the IM tuple presumably informs interested parties that the person will be available for chat the next day.  The Status-Text field of this protocol gives some of this functionality, but we are really assuming that ticker is the main messaging method.  Email addresses and other info can be supplied as an “x-” field. For more info see IMPP charter page, IMPP main page, IMPP working group pages and Lotus Research. 4.1.3        Jabber Jabber is an IM/presence service built from a series of federated servers.  The protocol is open and there are a number of open-source clients.  A free trialware server for up to 100 users is available, but a commercial license is needed for larger numbers of users. The XML-based Jabber protocol includes a presence message type.  Example (from protocol page):       Stay but a little, I will come again.    away    The distinction between ‘show’ and ‘status’ is interesting.  Status is user-readable text and is used in the same way the protocol in this document.  ‘Show’ can be:
chat The client is available for immediate contact. away The client is online, but is momentarily away (e.g., at lunch or a meeting). xa The client is online, but has been inactive for a long time. dnd The client is in Do Not Disturb mode. The Elvin presence protocol currently overloads show and status into the ‘Status’ field eg “Unavailable (at meeting in rm 56)” is the same as Jabber show = “away” + status = “at meeting in rm 56”.  We may want to consider following the Jabber example. Jabber also has an “iq” message format can be used to exchange extended information. See home page, main commercial page, Jabber Central news page 4.1.4        ICQ The ICQ v5 protocol allows a range of, non-extensible (?) information about a user to be published using the CMD_META_USER message such as name, phone, age, city etc.  This sort of information could be accommodated by the Elvin presence protocol using x-Name, x-Phone etc. See ICQ protocol site. From kas-list at magnetic-ink.dk Thu Oct 4 21:26:51 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EB0B@salex005.dsto.defence.gov.au> Message-ID: <20011004132659.A20310@magnetic-ink.dk> Matthew Phillips wrote: > I've been converted to the idea of supporting multiple presence > groups and keeping the user@domain concept seperate. I've also > renamed the term "domain" to "group". Nice. :-) > Attached is a revised draft spec for comment. I don't have any other comments than: what is the significance of the leading and trailing |'s in Groups, Chat-Groups and News-Groups? As far as I can see they do not convey any additional information, and we can get the same functionality by omitting the |'s (something that, accidentally, makes it easier to parse the fields from within Python), so that we have "group-1|group-2" rather than "|group-1|group-2|". Apart from that I'm ready to implement this spec. Btw, can we use this scheme for bots also (bots could have their own group - botspot, or whatever)? Cheers, // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From julian at dstc.monash.edu.au Thu Oct 4 22:04:25 2001 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EB0B@salex005.dsto.defence.gov.au> Message-ID: <200110041204.f94C4mV03974@xevious.dstc.monash.edu.au> "Phillips, Matthew" wrote: > Attached is a revised draft spec for comment. I haven't had any non > domain-related feedback on the previous one, and I hope this is a sign of > general consent rather than utter boredom. not utter boredom, but i've been lost in other things, sorry ;-( I am alot more happy with the new spec and the mulitple-groups option. David mentioned some ontological issues the other day. this related to another discussion about attriubute naming in notifs in general. for the moment, I don't think its worth worrying too much about this? I'm happy to implement the proposed spec, and perhaps use it as the basis for further name disussions in future. oh, and the leading '|' has me curiuos as well? thanks, Mathew. -J From Martin.Wanicki at Australia.Boeing.com Fri Oct 5 09:00:55 2001 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 Message-ID: <21BEC9503B89D111A8F700805FE6A3690A0A78D1@xch-bne-01.bal.bna.boeing.com> It all looks good to me. I'm also ready to implement. And just to jump on the band wagon, the pipe symbols are a little ugly and a little overused. A separating delimiter seems to be a common practice & a defacto standard as in Klaus's example. ("group-1|group-2" ) I would also prefer the semi colon ";" (also a defacto standard in the winblows world) instead of the pipe "|" Apart from that I'm chompin at the bit to get at this... Cheers all, Martin Email Boeing = martin.wanicki@boeing.com DSTC = mwanicki@dstc.edu.au From agerber at dstc.edu.au Fri Oct 5 10:24:30 2001 From: agerber at dstc.edu.au (Anna Gerber) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <20011004132659.A20310@magnetic-ink.dk> Message-ID: > > I've been converted to the idea of supporting multiple presence > > groups and keeping the user@domain concept seperate. I've also > > renamed the term "domain" to "group". > > Nice. :-) I've probably missed some previous discussion about this before, but I'm a bit concerned about the meaning of 'groups': It seems to be used to mean both domains to which a user belongs and channels to which a user is subscribed in this protocol. I'd prefer not to use the same word for two different concepts here. (The proposed bot protocol makes yet another use of the word 'group' to represent the class of bots to which a bot belongs, I'll rename it to avoid overloading the word) > Btw, can we use this scheme for bots also (bots could have their own > group - botspot, or whatever)? Yes, this would be a good idea. Anna From Matthew.Phillips at dsto.defence.gov.au Fri Oct 5 11:07:44 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB0F@salex005.dsto.defence.gov.au> Julian: "David mentioned some ontological issues the other day. this related to another discussion about attriubute naming in notifs in general. for the moment, I don't think its worth worrying too much about this? I'm happy to implement the proposed spec, and perhaps use it as the basis for further name disussions in future." This sounds interesting. Can you or David summarise this at all? Klaus: "Btw, can we use this scheme for bots also (bots could have their own group - botspot, or whatever)?" Absolutely. I's say either use one "bots" group or maybe several with a naming convention like "bots.dstc", "bots.public" etc. Several people have noted the "|" convention for formatting group sets. The reason for this is that clients will often want to subscribe for presence info for a single group, and with this convention we can just use a subscription like: require(Presence-Info) && contains(Groups, "|dsto|") This will then catch notifications where the Groups field is just "|dsto|", or where it is "|elvin-sse|dsto|" and also distinguishes it from "|ftd.dsto|bobco|". Just using contains(Groups, "dsto") could catch other notifications, and the alternative, where we use ";" as a separator would need the horrible expression: contains(Groups, ";dsto;") || ends-with(Groups, ";dsto") || begins-with(Groups, "dsto;") || Groups == "dsto" The reason to choose "|" over ";" or "," is that it looks better when used this way ie "|dsto|elvin-sse|" looks nicer than ";dsto;elvin-sse;", IMHO. Cheers, Matthew. From Martin.Wanicki at Australia.Boeing.com Fri Oct 5 13:01:38 2001 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 - separators Message-ID: <21BEC9503B89D111A8F700805FE6A3690A129082@xch-bne-01.bal.bna.boeing.com> Ok, I'm understanding the reason for enclosing the group in a delimiter pair it clearly makes the subscriptions easier. It does seem tho, that the spec should not call them separators but should instead enforce the wrapping of the group names in a delimiter pair. This concept seems useful for other things like ( and I hate to bring it up again) distribution, and any attribute value containing a list of channels, groups, usernames ..etc To that end it may be good to spend a few minutes thinking about this methods application to other formats and incorperate it as a base spec for such lists. It would be handy not to have to develop more that one parsing routine for each incarnation :-) Just to be different - and probably annoying:-( what about using some sort of bracketing characters instead ? So a subs might look like require(Presence-Info) && contains(Groups, "","","","") or require(Presence-Info) && contains(Groups, "{dsto}","{foo.bar}","{bad ideas}","{good ideas}") or require(Presence-Info) && contains(Groups, "[dsto]","[foo.bar]","[bad ideas]","[good ideas]") or even require(Presence-Info) && contains(Groups, "(dsto)","(foo.bar)","(bad ideas)","(good ideas)") personally I like the or [value] versions :-) cheers, Martin eMails : Boeing = martin.wanicki@boeing.com DSTC = mwanicki@dstc.edu.au From julian at dstc.monash.edu.au Fri Oct 5 13:40:20 2001 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:38 2003 Subject: Ontologies in elvin notifications Message-ID: <200110050340.f953eiV07756@xevious.dstc.monash.edu.au> a repost summarising one discussion at the end of teh ticker workshop, although not by any means meant as minutes... trying to define "group" would be even harder than user ;-( -J ------- Forwarded Message Date: Mon, 17 Sep 2001 10:36:16 +1000 From: Julian Boot Subject: [elvin-dev] notification naming conventions Sender: owner-elvin-dev@dstc.edu.au To: elvin-dev@dstc.edu.au Cc: agerber@dstc.edu.au Reply-to: julian boot Message-id: <200109170036.f8H0aG729336@xevious.dstc.monash.edu.au> Content-transfer-encoding: 7BIT Precedence: bulk X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/) X-Virus-Scanned: by AMaViS perl-11 Someting that has been bugging me for sometime is how the dynamic nature of elvin can be managed better accross different applications. Notifications in elvin are by design free-form. however, while this provides desirable characteristics in terms of loose coupling, it also leads to clashes in terms of semantics accross applications. An example of this would be a "User" field which is used as a nickname in a messaging application, but a unix UID in a filewatcher. while we have traditionally ignored these instances "as the nature of elvin", I don't think this attitude is counter-intuitive and a simple alternative is possible. In a global[0] elvin network, it is desirable to receive information on a single user, eg "contains(User, 'Smith')". If you have two differnt notification formats, we have a problem. eg: - --- CoffeeBiff: 1 User: "Smith" Timeout: 10 - --- FileWatcher: 1 User: 666 UserName: "Agent Smith" File: "/etc/passwd" Action: "edit" - --- A single consumer that wishes to track smith must be aware of all the different fields in which "Smith" appears (as elvin does not allow for a subscription of "contains(*, 'Smith')"). The consumer needs to use "contains(User, 'Smith') || contains(UserName, 'Smith')". For a network with even more applications, this consumer is going to struggle to route the content of interest. It implies a level of coupling which is not desirable and begs the question of how useful is content routing accross multiple applications or domains? There are any number of ways to try and reduce this problem. I would like o propose a simple and I think possibly the most useful way of maintaining the semantics of notification attributes accross applications. For common english words (we only allow 7-bit ascii in attribute names) I would like elvin.org to maintain a registry of definitions which define a single semantic for each word. So: User: Informal name of a person interacting with a system component UID: A numeric user id used to define a user This registry would serve the same purpose as RFC 2119 for internet drafts. If an application has a user-like field, the developer can check existing definitions and decide the best name to use. A notification which obeys such rules could be tagged with a flag, such as schema.elvin.org: "1.0" to indicate to consumers that it can expect sane values in the delivered notification. I expect this to be contentious, but believe it to be necessary. Comments? - -J [0] where global is any elvin network with more than one application using elvin. - ---- julian boot ))X(( senior research scientist elvin http://elvin.dstc.edu.au ------- End of Forwarded Message From kas-list at magnetic-ink.dk Fri Oct 5 22:35:51 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EB0F@salex005.dsto.defence.gov.au> Message-ID: <20011005143545.A7483@magnetic-ink.dk> Matthew Phillips wrote: > I's say either use one "bots" group or maybe several with a > naming convention like "bots.dstc", "bots.public" etc. That's a good idea. > Several people have noted the "|" convention for formatting group > sets. The reason for this is that clients will often want to subscribe > for presence info for a single group, and with this convention we > can just use a subscription like: > > require(Presence-Info) && contains(Groups, "|dsto|") You're right, I only thought about require() and regex() subscriptions, and never considered the possibility you're mentioning. I reckon I can accept this as a valid argument for using leading and trailing group delimiters. > The reason to choose "|" over ";" or "," is that it looks better > when used this way ie "|dsto|elvin-sse|" looks nicer than > ";dsto;elvin-sse;", IMHO. I agree with you inasmuch as I never liked the ';' construct. On the other hand I, as a user, should never have to actually see those strings as I expect my software to handle the details for me. But yes, '|' do look nicer than ';'. We could also, as Martin suggests, use a pair of symbols <{([])}> to enclose each and every group subscribed to. I'm not sure which idea I like the best... // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From kas-list at magnetic-ink.dk Fri Oct 5 22:40:34 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <20011004132659.A20310@magnetic-ink.dk> Message-ID: <20011005144031.B7483@magnetic-ink.dk> Anna Gerber wrote: > I'm a bit concerned about the meaning of 'groups' It's becoming a bit overloaded, yes. How about "worksgroups", then, or is it too Windowish? > The proposed bot protocol [...] I'm *very* interested in developing some useful bots for Elvin, is the protocol you're mentioning available from somewhere? // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From lawley at dstc.edu.au Sun Oct 7 14:15:44 2001 From: lawley at dstc.edu.au (Michael Lawley) Date: Tue Oct 14 08:01:38 2003 Subject: [OT] RE: [ticker-dev] Elvin presence specification draft 0.2 - separators Message-ID: <200110070415.f974FiE08337@piglet.dstc.edu.au> This discussion re separators just makes me laugh 'til I cry. When will Elvin get a list/set type? michael, grinding the same old axe :-) -- Michael Lawley, http://purl.org/NET/lawley Scientician. DSTC hosts the Australian W3C Office From agerber at dstc.edu.au Mon Oct 8 11:16:44 2001 From: agerber at dstc.edu.au (Anna Gerber) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <20011005144031.B7483@magnetic-ink.dk> Message-ID: > I'm *very* interested in developing some useful bots for Elvin, is > the protocol you're mentioning available from somewhere? There is some information describing how the meta-bot uses the bot protocol available at: http://staff.dstc.edu.au/agerber/meta-bot.html http://elvin.dstc.edu.au/ticker2001/minutes/interactive_bots/1.html (buried in further in the slides) Anna From lawley at dstc.edu.au Mon Oct 8 14:21:18 2001 From: lawley at dstc.edu.au (Michael Lawley) Date: Tue Oct 14 08:01:38 2003 Subject: presence protocol Message-ID: <200110080421.f984LIE15002@piglet.dstc.edu.au> Hi, last night I threw together a simplistic implementation of the 0.2 version of the presence protocol for aquatik. This lead me to two questions: * Is anoyone else running anything that implements this? * How do I discover what 'groups' exist? With the protocol as specified, this does not seem possible (except via quench). michael "analog - the new digital" -- Michael Lawley, http://purl.org/NET/lawley Scientician. DSTC hosts the Australian W3C Office From Matthew.Phillips at dsto.defence.gov.au Mon Oct 8 15:13:18 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:38 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB17@salex005.dsto.defence.gov.au> Klaus (and in reply to Martin also): > > The reason to choose "|" over ";" or "," is that it looks better > > when used this way ie "|dsto|elvin-sse|" looks nicer than > > ";dsto;elvin-sse;", IMHO. > > I agree with you inasmuch as I never liked the ';' construct. On the > other hand I, as a user, should never have to actually see > those strings > as I expect my software to handle the details for me. But yes, '|' do > look nicer than ';'. We could also, as Martin suggests, use a pair of > symbols <{([])}> to enclose each and every group subscribed to. I'm > not sure which idea I like the best... You're right about this being a client-level thing and not really important. I did consider something like "{dsto}{dstc}{bobco}" for groups, but it's really just wasting bytes in "syntactic sugar" for something that very few people are ever going to want to see anyway. Michael: > * Is anoyone else running anything that implements this? As far as I know the answer is no - the 0.2 spec has only been out for 4 days now, and I have been waiting for comments before taking the leap. It won't take long to change Sticker 2 over though, it's mainly a matter of renaming some fields. Adding GUI support for multiple groups might take a little bit longer though. (I also want to see if I can support the older Sticker 1 presence protocol, since quite a few people are using it here) > * How do I discover what 'groups' exist? With the protocol > as specified, this does not seem possible (except via quench). Good question. Word of mouth or ticker is one way. "require(Presence-Info)" is another way, albeit one that could potentially flood your client. We may have to put in a simple server running on one of the gateways that compiles a group list from Presence-Info notifications and can spit it out to interested clients. Matthew. From kas-list at magnetic-ink.dk Tue Oct 9 02:29:40 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] Elvin presence specification draft 0.2 In-Reply-To: <20011005144031.B7483@magnetic-ink.dk> Message-ID: <20011008182937.A19093@magnetic-ink.dk> Anna Gerber wrote: > There is some information describing how the meta-bot uses the > bot protocol available at: > http://staff.dstc.edu.au/agerber/meta-bot.html > http://elvin.dstc.edu.au/ticker2001/minutes/interactive_bots/1.html Ta, I'll have a look at it. // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From arnold at dstc.monash.edu.au Sun Oct 14 14:33:29 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: presence spec Message-ID: <200110140433.f9E4Xl412285@xevious.dstc.monash.edu.au> sorry this has taken so long, but i've finally got some comments on draft two of the presence spec. this morning i hacked up a Python/GTK presence client. ftp://ftp.dstc.edu.au/DSTC/elvin/epm-0.1.tar.gz you'll need Python1.6 or later, pe-4.0b1 or later, and PyGTK (i used 0.6.6 happily). this is a slightly difficult combination, since many Linux distributions still use Python1.5, and pe4 needs 1.6, but ... for those unable/unwilling to install the required stuff, it's a very simple UI: a multiple column list showing User, Time, Status and a combo box below that for your own status text. at this stage the time display is completely bogus: every 10 seconds, it adds 10 to whatever value is displayed. i couldn't be bothering doing it better, since the real intention was to test the protocol. so, i have a couple of comments to make on the draft spec: - it's good. thanks Matthew! - section 3.1, says that the name and domain are case *in*sensitive strings. are we sure that ignoring case differences are the best thing to do here? it works for English, but i'm not sure how other languages/cultures deal with this. if we're to ignore case, all the example subscriptions later in the spec are incorrect, since they're not using the fold-case() sub-lang function. - in section 3.2, i think the first paragraph could use some re-wording to make clear that the user's domain is their default group. Matthew? if you'd like me to send you some text, let me know. - throughout the document, i think we would do well to adopt the IETF's terminology for requirements, as specified in RFC-2119. i think this would help clarify statements of expectation from requirements of the spec, etc. see: ftp://ftp.ietf.org/rfc/rfc2119.txt - i think some explanation of the requirement for Status-Duration rather than a timestamp would be worthwhile. the rationale of machines with broken clocks and timezone challenges is fine, but it should be in the document. - section 3.4, step 1 of Frodo's client's actions. the subscription shown does not illstrate the use of groups in addition to the default domain-group, nor direct subscriptions to a specified user. it'd be good to have an example of this more complete subscription in the spec. one from epm -- require(Presence-Info) && ( \ contains(Groups, "|listen-group-1|") || \ contains(Groups, "|listen-group-2|") || \ contains(Groups, "|example-domain|") || \ User == "extra-user@domain" \ ) note that this is a case-sensitive subscription! - in section 3.4, in the Presence-Request event, the 'Groups' field is mandatory. when requesting information about a non-group buddy, what should i put in the 'Groups' field? i could put the domain part of the user name, but that seems redundant? - in section 3.4, in the Presence-Request event, the 'User' field is singlular. this means that i need to send one request for each of my non-group buddies. if the 'User' field were to become 'Users' with the same list syntax as the 'Groups' field, a starting presence client would only need to send 3 notifications: request for groups, request for users, and its own new status. - in section 3.4, in the Presence-Request example subscription, the 'User' field does not contain the domain part of the user's name. elsewhere in the spec, all 'User' fields contain the fully-qualified user name. in epm, i used the fully-qualified name here. - in section 3.4, in the Presence-Request example subscription, the 'User' field is conjoined with the 'Groups' field. this means that the example subscription will not receive requests for a non-group user. in epm, i altered this subscription to be require(Presence-Request) && ( \ User == "user@domain" || ( \ User == "*" && ( \ contains(Groups, "|domain|") || \ contains(Groups, "|member-group-1|") || \ contains(Groups, "|member-group-2|") || \ contains(Groups, "|member-group-3|") \ ) \ ) \ ) - in section 3.4, in the sample Presence-Info reply, the value of the Presence-Info field contains both the word 'reply' and the unique reply tag. do we need the word 'reply' here? i know it's easy enough to match using contains(unique-tag), but is a simple equality test better? this would require that the unique tag never be 'initial' or 'update', which is faily easy to implement. - in section 3.5, the 'User' field specification has issues as described above. - in section 3.6, the 'User' field definition does not require the @-sign or domain to be included. this should be clarified and made explicit. - in section 3.6, the 'Status-Text' field definition doesn't explicitly state whether the example values must be supported by a client. as suggested in section 4.1.3, it might be useful to split the status into a semantic flag, and a displayed text. this would possibly help with multi-lingual clients also, where, for example, the use of "Unavailable" as the status might be meaningless. i'd like to discuss this further. sorry this is so late, and long. hopefully it's useful! d From arnold at dstc.monash.edu.au Sun Oct 14 14:53:05 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence spec In-Reply-To: <200110140433.f9E4Xl412285@xevious.dstc.monash.edu.au> Message-ID: <200110140453.f9E4rN412337@xevious.dstc.monash.edu.au> oh, and one other thing i thought of, but didn't do anything about yet: if a user is running multiple presence clients, info requests will generate multiple responses. the spec should mention this, and i'd suggest that clients ignore any presence information with a duration longer than the duration of the last-received status ? in other words, display the most recently changed information. sound ok? d From arnold at dstc.monash.edu.au Mon Oct 15 00:13:01 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence protocol In-Reply-To: <200110080421.f984LIE15002@piglet.dstc.edu.au> Message-ID: <200110141413.f9EEDJ413152@xevious.dstc.monash.edu.au> -->"Michael" == Michael Lawley writes: Michael> Is anoyone else running anything that implements this? i am now. it'll be online more-or-less all the time from tomorrow. i have also set the DSTC federation to forward these events internally and to the public router (for the moment, at least). Michael> How do I discover what 'groups' exist? With the protocol Michael> as specified, this does not seem possible (except via Michael> quench). you can get partial information by noting what groups others in your default domain-group are members of in the Presence-Info events. d From arnold at dstc.monash.edu.au Tue Oct 16 23:14:31 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: presence proxy agent Message-ID: <200110161314.f9GDEb426603@xevious.dstc.monash.edu.au> i was thinking last night that once a presence client is no longer running (or otherwise not responding), it is unable to service queries from others' clients. it would be possible to write a simple bot that listened to Presence-Info events, and kept track of the last-updated status for each user. if the user's client failed to respond to a Presence-Request within, say, 30 seconds, this bot could then 'adopt' that user, and respond on their behalf. when the user's client rejoins the network, and responds on its own behalf again, the bot can revert to silent listening. the collision of replies when the client restarts is dealt with by accepting the one with the smaller Status-Duration value (as per the multi-client scenario). it might also be useful to add an additional field to the notification indicating that the response is by proxy. this could (perhaps) be shown by the GUI, but in particular would prevent multiple bots from mistaking each other for the user's client. something like Proxy: "hq.dstc.com" where the value is some string suitable for filtering? this field might also be helpful for filtering the propagation of proxied presence events to prevent such occurances ;-) the use of a timeout to determine that the client is no longer active is a little grubby, but using an explicit handover protocol seems like overkill. comments? d From Matthew.Phillips at dsto.defence.gov.au Wed Oct 17 11:14:57 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB3B@salex005.dsto.defence.gov.au> I like the idea of a proxy presence service a lot. I got excited a few months ago and started writing one as part of a generic host for Java bots/services, but only got as far as creating a directory structure for it :/ > the use of a timeout to determine that the client is no longer active > is a little grubby, but using an explicit handover protocol seems like > overkill. I think this would work well in practice. Also, most clients will exit properly and set their status to "Offline", at which point a bot could 'adopt' that person until it sees another status update from a non-bot. P.S. David, I've been meaning to go through your comments on the 0.2 spec properly. At first blush they all look valid, so a 0.3 revision will probably be forthcoming in the next day or two. P.P.S Is anything happening about Ticker 3.0? From kas-list at magnetic-ink.dk Wed Oct 17 13:26:32 2001 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EB3B@salex005.dsto.defence.gov.au> Message-ID: <20011017052630.A24260@magnetic-ink.dk> Matthew Phillips wrote: > Also, most clients will exit properly and set their status to > "Offline", at which point a bot could 'adopt' that person until > it sees another status update from a non-bot. Perhaps this is a dumb question, but why would I want a bot to respond on my behalf when I'm offline? So that my online buddies can see that I'm offline? Who's gonna build the first ECQ? *;) // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From arnold at dstc.monash.edu.au Wed Oct 17 13:33:09 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent In-Reply-To: <20011017052630.A24260@magnetic-ink.dk> Message-ID: <200110170333.f9H3XH401662@xevious.dstc.monash.edu.au> -->"Klaus" == Klaus Alexander Seistrup writes: Klaus> Perhaps this is a dumb question, but why would I want a bot Klaus> to respond on my behalf when I'm offline? if i'm going to be offline, i might want to explain why ... for example, "on vacation, back 1st nov" or "flying to tokyo" or whatever. i reckon it could be useful for my "buddies" to be able to discover this, without relying on a single, central server even if my client is not active? d From arnold at dstc.monash.edu.au Wed Oct 17 15:53:05 2001 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EB3A@salex005.dsto.defence.gov.au> Message-ID: <200110170538.f9H5cB402461@xevious.dstc.monash.edu.au> -->"Matthew" == Phillips, Matthew writes: Matthew> I like the idea of a proxy presence service a lot. cool. whipping one up from the core of epm should be triv -- i might have a bash tonight. Matthew> I've been meaning to go through your comments on the 0.2 Matthew> spec properly. At first blush they all look valid, so a Matthew> 0.3 revision will probably be forthcoming in the next day Matthew> or two. cool. Matthew> Is anything happening about Ticker 3.0? i have a partially done draft at home. i'll try to post it within the next couple of days ... d From lawley at dstc.edu.au Wed Oct 17 16:07:38 2001 From: lawley at dstc.edu.au (Michael Lawley) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent In-Reply-To: <200110170333.f9H3XH401662@xevious.dstc.monash.edu.au> Message-ID: <200110170607.f9H67cc09558@piglet.dstc.edu.au> David Arnold wrote: > -->"Klaus" == Klaus Alexander Seistrup writes: > Klaus>Perhaps this is a dumb question, but why would I want a bot > Klaus>to respond on my behalf when I'm offline? > if i'm going to be offline, i might want to explain why ... for > example, "on vacation, back 1st nov" or "flying to tokyo" or whatever. > i reckon it could be useful for my "buddies" to be able to discover > this, without relying on a single, central server even if my client is > not active? y'know, a proper persistent tuple space (linda :-) would be just the ticket here. |v| "analog - the new digital" -- Michael Lawley, http://purl.org/NET/lawley Scientician. From ilister at dstc.edu.au Wed Oct 17 16:14:59 2001 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:39 2003 Subject: [ticker-dev] presence proxy agent In-Reply-To: <200110170607.f9H67cc09558@piglet.dstc.edu.au> Message-ID: On Wed, 17 Oct 2001, Michael Lawley wrote: >y'know, a proper persistent tuple space (linda :-) would be just the >ticket here. Or a generalised Elvin persistence mechanism. I'm quite surprised that David suggested an application-specific one over a general one :-) Ian From Matthew.Phillips at dsto.defence.gov.au Wed Oct 17 16:45:16 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:39 2003 Subject: presence spec Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB3E@salex005.dsto.defence.gov.au> Hi David, all. Finally found the time to do David's comments justice: > - section 3.1, says that the name and domain are case *in*sensitive > strings. are we sure that ignoring case differences are the best > thing to do here? it works for English, but i'm not sure how other > languages/cultures deal with this. I've added a note on the reasons behind this. Essentially, standardising on case-insenstive groups, domains and user names avoids the confusion of not seeing people just because you got the case of the username or group wrong. It does make the subscriptions a little cruftier, but I think it's manageable. > if we're to ignore case, all the example subscriptions later in the > spec are incorrect, since they're not using the fold-case() sub-lang > function. Corrected. > - in section 3.2, i think the first paragraph could use some > re-wording to make clear that the user's domain is their default > group. Matthew? if you'd like me to send you some text, let me > know. I left this out as I think this is more of a client policy thing than a spec thing. Eg I don't think a presence client should force you to be in the '0x1.org' group just because you are d@0x1.org. In Sticker I do intend, by default, to put the user in a group that the same as their domain, but they could later remove that group and add others. > - throughout the document, i think we would do well to adopt the > IETF's terminology for requirements, as specified in RFC-2119. i > think this would help clarify statements of expectation from > requirements of the spec, etc. > > see: ftp://ftp.ietf.org/rfc/rfc2119.txt Good idea, I have revised some wording in light of this and added a note at the top. > - i think some explanation of the requirement for Status-Duration > rather than a timestamp would be worthwhile. the rationale of > machines with broken clocks and timezone challenges is fine, but it > should be in the document. Note added to description of Status-Duration. > - section 3.4, step 1 of Frodo's client's actions. the subscription > shown does not illstrate the use of groups in addition to the > default domain-group, nor direct subscriptions to a specified user. > > it'd be good to have an example of this more complete subscription > in the spec. one from epm -- > > require(Presence-Info) && ( \ > contains(Groups, "|listen-group-1|") || \ > contains(Groups, "|listen-group-2|") || \ > contains(Groups, "|example-domain|") || \ > User == "extra-user@domain" \ > ) > > note that this is a case-sensitive subscription! Agreed, but I want to start with a simple example to avoid freaking people out with complicated expressions. I've added section 3.5 that has a more complex example. > - in section 3.4, in the Presence-Request event, the 'Groups' field is > mandatory. > > when requesting information about a non-group buddy, what should i > put in the 'Groups' field? i could put the domain part of the user > name, but that seems redundant? Good point - in this case the Groups field is irrelevant, so I guess we use "*". > - in section 3.4, in the Presence-Request event, the 'User' field is > singlular. > > this means that i need to send one request for each of > my non-group buddies. > > if the 'User' field were to become 'Users' with the same list syntax > as the 'Groups' field, a starting presence client would only need to > send 3 notifications: request for groups, request for users, and its > own new status. Agreed, spec duly updated. > - in section 3.4, in the Presence-Request example subscription, the > 'User' field does not contain the domain part of the user's name. > elsewhere in the spec, all 'User' fields contain the fully-qualified > user name. > > in epm, i used the fully-qualified name here. Yes, that was a typo - the full name should always be used. > - in section 3.4, in the Presence-Request example subscription, the > 'User' field is conjoined with the 'Groups' field. this means that > the example subscription will not receive requests for a non-group > user. > > in epm, i altered this subscription to be > > require(Presence-Request) && ( \ > User == "user@domain" || ( \ > User == "*" && ( \ > contains(Groups, "|domain|") || \ > contains(Groups, "|member-group-1|") || \ > contains(Groups, "|member-group-2|") || \ > contains(Groups, "|member-group-3|") \ > ) \ > ) \ > ) The examples have been updated for the change from User to Users. One impact of this is that clients no longer need to check for "*": they just check to see if either they are in the requested user set, or one of their groups is in the requested group set. > - in section 3.4, in the sample Presence-Info reply, the value of the > Presence-Info field contains both the word 'reply' and the unique > reply tag. > > do we need the word 'reply' here? i know it's easy enough to match > using contains(unique-tag), but is a simple equality test better? > > this would require that the unique tag never be 'initial' or > 'update', which is faily easy to implement. I have no strong feelings on this, and I guess an equality test is marginally faster to match on the server, so I am happy to ditch it. > - in section 3.5, the 'User' field specification has issues as > described above. > > - in section 3.6, the 'User' field definition does not require the > @-sign or domain to be included. this should be clarified and made > explicit. Done. > - in section 3.6, the 'Status-Text' field definition doesn't > explicitly state whether the example values must be supported by a > client. > > as suggested in section 4.1.3, it might be useful to split the > status into a semantic flag, and a displayed text. this would > possibly help with multi-lingual clients also, where, for example, > the use of "Unavailable" as the status might be meaningless. > > i'd like to discuss this further. Your point about other languages is the decider on this one. I've added a Status field as well as the Status-Text field, which no longer has any conventional meaning and can be any text. I've also added an optional Requestor field to Presence-Request (see notes). Phew, another major email epic completed. Many thanks for your incisive comments David. Stay tuned for the 0.3 draft. Matthew. From Matthew.Phillips at dsto.defence.gov.au Wed Oct 17 16:50:36 2001 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:39 2003 Subject: Presence specification draft 0.3 Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB3F@salex005.dsto.defence.gov.au> Updated in response to David's comments <> Title: Elvin Presence Protocol Elvin Presence Protocol Matthew Phillips Draft 0.3 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 17/10/2001)   Contents  TOC \o "2-2" \h \z \t "Heading 1,1" Notes About This Document PAGEREF _Toc527968115 \h 1 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100310035000000 1      Aim   PAGEREF _Toc527968116 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100310036000000 2        Requirements  PAGEREF _Toc527968117 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100310037000000 3        Specification  PAGEREF _Toc527968118 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100310038000000 3.1       User Identity  PAGEREF _Toc527968119 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100310039000000 3.2       Groups. PAGEREF _Toc527968120 \h 2 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320030000000 3.3            Operation  PAGEREF _Toc527968121 \h 3 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320031000000 3.4            Example Exchange  PAGEREF _Toc527968122 \h 3 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320032000000 3.5            Example With Multiple Groups  PAGEREF _Toc527968123 \h 4 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320033000000 3.6            Presence Request Fields  PAGEREF _Toc527968124 \h 5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320034000000 3.7            Presence Info Fields  PAGEREF _Toc527968125 \h 5 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320035000000 3.8            Handling Conflicting Presence-Info Responses  PAGEREF _Toc527968126 \h 9 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320036000000 3.9       Notes. PAGEREF _Toc527968127 \h 9 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320037000000 4        References  PAGEREF _Toc527968128 \h 10 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320038000000 4.1       Other Presence Protocols  PAGEREF _Toc527968129 \h 10 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320037003900360038003100320039000000  

Notes About This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119. Changes to the previous 0.2 draft specification are highlighted in green. 1         Aim The aim of the presence protocol is to provide a simple and flexible means for Elvin users to communicate their presence online and publish information they may wish to have known about themselves. 2         Requirements Presence services are already provided to a greater or lesser extent by a number of applications, including ‘finger’, CoffeeBiff and various Instant Messaging (IM) clients such as Jabber and ICQ.  The primary reasons for, and advantages of, providing presence information via the Elvin presence protocol are:

·        Does not require centralised, persistent state.

·        Simple and thus easy to support.

·        Separate, but complementary to, ticker messaging.

·        Extensible. 3         Specification This section describes the protocol, including the operations between clients and the format of the presence notifications. 3.1        User Identity The presence protocol assumes that users are identified by a combination of name and domain, both of which are case-insensitive strings containing any character except ‘@’.  The combination of name@domain forms a unique user ID for the user in ‘presence space’ in the same manner as an email address. 3.2        Groups A group is a namespace containing a set of online users.  Every online user will MUST be in at least one group and may opt to be in several.  All users within a group will be aware of each other’s presence by default.  A group can be thought of as a public, dynamic ‘buddy list’ that is automatically populated with community of people.  When users want to add people outside their main group to their buddy list, they have two options: explicitly add the other user by name, or join the other group. For example, suppose all the people working in the Frob Testing Division of Bob’s Frobs Inc, may elect to be in the ‘ftc.bobco’ group.   The manager of FTC might also elect to be in the ‘management.bobco’ group so they can maintain contact with the managers of other divisions. As well as providing a way to partition presence information into communities, the group concept is the key to scalability of the presence protocol by making it efficient for clients to subscribe to all presence info in a group, knowing this won’t bog down the entire online world. 3.3        Operation The presence protocol operates by exchanging two types of notifications:

·        Presence-Info, and

·        Presence-Request Clients use Presence-Info notifications to publish presence information about themselves, and use Presence-Request to trigger other clients to generate info notifications. Clients subscribe to Presence-Request notifications, and generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up and when any of the presence information previously published has changed.  A number of fields in Presence-Info are optional, meaning they may be left out when their values are the same as they were in the last full notification. 3.4        Example Exchange Note: see sections 3.6 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000 & 3.7 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000 for definitions of the Presence-Request and Presence-Info notifications. Scenario: Zaphod@hitch-hikers is already online.  Frodo@hitch-hikers, starts up a presence-capable client.  Both are in the ‘hitch-hikers’ group. Frodo initially announces he is online with the following full presence info notification:

    Presence-Info: initial Presence-Protocol: 1000              User: Frodo@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Online   Status-Duration: 0       Chat-Groups: |Chat|ticker-dev|       News-Groups: |BreakingStories|Slashdot|     Ticker-Client: frodoticker 1.0 Zaphod’s client, being subscribed to presence info in for the hitch-hikers group, receives the information about Frodo and updates its registry. Frodo’s client now populates its registry by:

1.      Subscribing to presence information for the hitch-hikers group using the expression: require (Presence-Info) &&     contains (fold-case (Groups), “|hitch-hikers|”)

2.      Sending a request for presence information about people in the current group.  The presence request notification Frodo sends is:  Presence-Request: cafebabe12345 Presence-Protocol: 1000          Reqestor: Frodo@hitch-hikers            Groups: |hitch-hikers|             Users: * All clients in the group, including Zaphod’s, receive the request since they have subscribed using an expression like: Require (Presence-Request) &&   (contains (fold-case (Groups), “|hitch-hikers|”) ||    contains (fold-case (Users), “|zaphod@hitch-hikers|”)) Zaphod’s client responds with a full presence info notification tagged with the request ID from Frodo’s message:

    Presence-Info: reply cafebabe12345 Presence-Protocol: 1000              User: Zaphod@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Online   Status-Duration: 42       Chat-Groups: |Chat|ticker-dev|       News-Groups: |BreakingStories|Slashdot|     Ticker-Client: zticker 3.0 x-Number-Of-Heads: 2 Frodo’s client updates its registry, at which point Zaphod, Frodo, and any other interested clients are in sync. Later, when Zaphod decides to go for coffee, he hits the “Coffee!” button on his client, which sends this partial presence notification:     Presence-Info: update Presence-Protocol: 1000              User: Zaphod@hitch-hikers            Groups: |hitch-hikers|       Status-Text: Coffee!   Status-Duration: 0 3.5        Example With Multiple Groups The previous example assumed Frodo was in a single group.  The following example (shown from Frodo’s end only) illustrates how his client would support Frodo being both in the ‘hitch-hikers’ group and the ‘hobbits’ group.  The key changes from the previous example are highlighted in bold. Frodo’s client would announce he is online with:

    Presence-Info: initial Presence-Protocol: 1000              User: Frodo@hitch-hikers            Groups: |hitch-hikers|hobbits|       Status-Text: Online   Status-Duration: 0       Chat-Groups: |Chat|ticker-dev|       News-Groups: |BreakingStories|Slashdot|     Ticker-Client: frodoticker 1.0 Frodo’s client subscribes to Presence-Request using this expression: require (Presence-Request) &&   contains (fold-case (Groups),

     “|hitch-hikers|”, “|hobbits|”) ||
  contains (fold-case (Users), “|frodo@hitch-hikers|”)







3.6       
Presence Request Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
  
   
   Presence-Request
   
   
   String
   
   
   Marks the notification as a presence request and
   carries a request ID.
   
   
   A random, unique request ID, not longer than 255
   characters, no spaces.  The ID MUST NOT be “initial” or “update”.
   
   
   Always
   
  
  
   
   Presence-Protocol
   
   
   Int32
   
   
   Same as Presence-Info
   
   
    
   
   
   Always
   
  
  
   
   Requestor
   
   
   String
   
   
   The
   username of the person requesting the presence information.
   
   
   A
   username in user@domain
   form.
   
   
   Optional
   
  
  
   
   Groups
   
   
   String
   
   
   Same as Presence-Info Allows a client to
   request status info of all users in a set of groups.
   
   
   A
   set of groups in the same format as Presence-Info or  “*’ when
   the User field contains a specific username.
   The User and Groups fields MUST NOT both be “*”.
   
   
   Always
   
  
  
   
   Users
   
   
   String
   
   
   Allows a client to request status info of a particular
   users Clients
   should respond to requests when the “Users” field matches contains their
   username.
   
   
   A specific usernameA set of usernames delimited by “|” or “*” (any
   user).
   Eg
   “|frodo@home|bob@bobco”.
   The User and
   Groups fields MUST NOT both be “*”.  
   
   
   Always
   
  
 


 

3.7       
Presence Info Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
 
 
  
  Presence-Info
  
  
  String
  
  
  Marks this as a presence info notification and specifies
  its subtype
  
  
  
·       
  “initial”: Full info, with all fields that the client
  supports populated.  Generated when
  the client starts and broadcasts initial presence info.
  
·       
  “reply  request_id”:
  Full info (all fields that the client supports are populated) in response to
  a Presence-Request with ID request_id.
  
·       
  “update”: Partial info, with only the optional fields
  that have changed since last update included.  Generated when presence data (eg Status-Text) changes.
  
  

  Always
  
 
 
  
  Presence-Protocol
  
  
  Int32
  
  
  The version of the presence protocol that is used in
  this notification.
  
  
   major_version
  * 1000 + minor_version.  Eg.
  2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for
  major/minor versions apply: major version number changes indicate
  incompatible changes to the protocol, minor number increments indicate
  backward-compatible changes to the protocol.
  
  
  Always
  
 
 
  
  User
  
  
  String
  
  
  The user’s username.
  
  
  Any username: eg “mpp@dsto”, “bob@bobco”, etc.
  
  
  Always
  
 
 
  
  Groups
  
  
  String
  
  
  The groups the user is a member of.
  
  
  A set of group names separated by ‘|’.
  For example “|dsto|quake heroes|”.
  Note that the preceding and trailing ‘|’s allow clients to easily use the
  ‘contains’ function to test for particular groups without having to handle
  three cases (ie where the group is at the beginning, middle and end of the
  list).
  
  
  Always
  
 
 
  
  Status
  
  
  String
  
  
  The
  status of the user.
  
  
  
·       
  “online”: the user is online and ready to receive
  messages.
  
·       
  “unavailable”: the user is not currently viewing
  messages (eg away from desk).
  
·       
  “unavailable?”: the client has automatically set
  this status based on activity (keystroke/mouse) monitoring, so this is an educated guess.
  
·       
   “offline”: the user is not
  currently connected.  This is usually
  sent as the status when a presence client disconnects.
  
·       
   “coffee”: the user is on a
  coffee break.
  The
  “online”, “offline” and “unavailable” settings SHOULD be taken into account by the client when merging
  conflicting notifications: see section  REF _Ref527966988
  \r \h 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for a discussion on this.
  
  

  Optional
  
 
 
  
  Status-Text
  
  
  String
  
  
  Text
  describing the status of the user.
  
  
  Any string intended to be displayed as the current status eg
  “Online: but will be away this afternoon”.
   
  
  
  Optional: required when the Status field is present
  
 
 
  
  Status-Duration
  
  
  Int32
  
  
  The amount of time (in seconds) that the current status
  has been in effect.  This is a relative duration rather than an absolute time since the
  status was set to
  avoid the perennial problems with inaccurate clocks and time zones.
  
  
  Any integer >= 0. 
  Undefined behaviour if anyone holds the same status longer than 136
  years ;) (232 seconds)
  
  
  Optional: required when Status field is present
  
 
 
  
  Chat-Groups
  
  
  String
  
  
  The set of chat groups the user is subscribed to.
  
  
  Eg. “|Chat|ticker-dev|”
  
  
  Optional
  
 
 
  
  News-Groups
  
  
  String
  
  
  The set of news groups the user is subscribed to.
  
  
  Eg. “|BreakingStories|Slashdot|”
  
  
  Optional
  
 
 
  
  Ticker-Client
  
  
  String
  
  
  The ticker client the user is running
  
  
  A ticker client name and version eg “sticker 2.0.1”,
  “xtickertape 2.0a”.  A missing value
  indicates the user is not running a ticker client.  Users that are running ticker that don’t wish the type of
  client to be known should use “generic”.
  
  
  Optional
  
 










3.8       
Handling
Conflicting Presence-Info Responses

Clients SHOULD handle the situation where multiple Presence-Info responses
are received for single user by using the precedence of the Status fields.  For example, in the case where a user is running two clients on
two hosts, one of which is listing the user as “unavailable?”, the other which lists the
user as “online”, Presence-Requests
will generate two responses.  In this
case, clients SHOULD clearly give precedence to the information in the “online” response over the “inactive?”.  The order of precedence is 
“online”, “unavailable”, “unavailable?” and “offline”, with other statuses being
equal bottom of the order.

3.9       
Notes


·       
Presence-Info: the values of this field have been
designed so that clients can easily discern the derivation of updates if they
wish (for efficiency or otherwise). 
However, clients are not required to distinguish between the different
types of Status-Info notification: simply updating a registry with the new data
in any Presence-Info notification is sufficient, so long as missing optional fields
are handled.

Note that one possible efficiency enabled by this approach is the ability to
opt out of redundant “reply” updates in response to a Presence-Request from
other clients, using the expression Status-Info != “reply”.  The other obvious way to mark replies to
status requests -- with a separate “In-Reply-To” field -- makes this difficult,
since !require
(In-Reply-To) can’t be used to create the same effect due to the
tri-state logic used in the Elvin subscription language.


·       
Presence-Protocol: this is designed so that clients can
subscribe to known protocol sets eg “Protocol-Version >= 1000 &&
Protocol-Version < 3000” picks up any 1.x or 2.x protocol
notifications.


·       
It is assumed that, if the user is running a ticker
client, then they are subscribed to their ‘personal’ chat group with the same
name as their user ID ie “user@domain”. 
This convention makes it obvious how to send a ticker message to someone
visible via the presence system.


·       
Non-standard fields should use the “x-” naming
convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to
display the non-standard fields.


·       
Treating
usernames or
groups as case-sensitive
runs the risk of
people not seeing each other because they got the case wrong eg I look for
‘bob@bobco’ and fail to see him because he is really ‘Bob@BobCo’.


·       
Requestor
field: this was
initially intended
to allow clients to respond differently depending on the requestor, eg subscriptions to some groups might be
hidden except to certain people.  But since any client can listen
in to the replies, it
would not be a particularly useful way of hiding information
(using the security API’s would make more sense).  It
is left in the
specification but
made optional.

4        
References

4.1       
Other Presence Protocols

Thanks to David Arnold for providing the initial set of
links that these references are based on.

4.1.1       
Simple General Awareness Protocol (SGAP)

A Lotus-sponsored IETF
Internet Draft, which expired on May 98. 
It’s not clear if this is still a live project.  Specification talks mainly about
client/server interactions and message formats.  Seems to offer little wisdom for this specification.

Also see Lotus
Research Page for more information.

4.1.2       
Instant Messaging and Presence Protocol (IMPP)

Uses presence information messages (MIME type
message/cpim) that contain an XML presence info ‘payload’.

Example payload (from IMPP
internet draft):

                         open                     away                       im:shingo@jp.fujitsu.com       I'll be in Tokyo tomorrow                          open              mailto:shingo@jp.fujitsu.com           

 

The main wisdom to be gained here is that the presence
info is divided into one or more contact tuples, which describe the users’
status in a particular online medium. 
In the example, the user is saying they have both Instant Messaging and
email contacts, but are not online for IM. 
The addition of the note to the IM tuple presumably informs interested
parties that the person will be available for chat the next day.  The Status-Text field of this protocol gives
some of this functionality, but we are really assuming that ticker is the main
messaging method.  Email addresses and
other info can be supplied as an “x-” field.

For more info see IMPP charter page,
IMPP main page, IMPP working group pages and
Lotus
Research.

4.1.3       
Jabber

Jabber is an IM/presence service built from a series of
federated servers.  The protocol is open
and there are a number of open-source clients. 
A free trialware server for up to 100 users is available, but a
commercial license is needed for larger numbers of users.

The XML-based Jabber protocol
includes a presence message type. 
Example (from protocol page):

      Stay but a little, I will come again.    away   

The distinction between
‘show’ and ‘status’ is interesting. 
Status is user-readable text and is used in the same way the protocol in
this document.  ‘Show’ can be:



 
  

  chat
  
  
  The client is available for immediate contact.
  
 
 
  
  away
  
  
  The client is online, but is momentarily away (e.g., at lunch or a
  meeting).
  
 
 
  
  xa
  
  
  The client is online, but has been inactive for a long time.
  
 
 
  
  dnd
  
  
  The client is in Do Not Disturb mode.
  
 


The Elvin presence protocol
currently overloads show and status into the ‘Status’ field eg
“Unavailable (at meeting in rm 56)” is the same as Jabber show = “away” +
status = “at meeting in rm 56”.  We may
want to consider following the Jabber example.

Jabber also has an “iq” message format can be used to
exchange extended information.

See home page, main commercial page, Jabber Central news page

4.1.4       
ICQ

The ICQ
v5 protocol allows a range of, non-extensible (?) information about a user
to be published using the CMD_META_USER message such as name, phone, age, city
etc.  This sort of information could be
accommodated by the Elvin presence protocol using x-Name, x-Phone etc.

See
ICQ protocol site.








From arnold at dstc.monash.edu.au  Wed Oct 17 16:52:21 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] presence proxy agent
In-Reply-To: <200110170607.f9H67cc09558@piglet.dstc.edu.au>
Message-ID: <200110170652.f9H6qK403782@xevious.dstc.monash.edu.au>


-->"Michael" == Michael Lawley  writes:

  Michael> y'know, a proper persistent tuple space (linda :-) would be
  Michael> just the ticket here.

maybe.  linda is a fine model.

 from an implementation point of view (and this is probably more
elvin-dev fodder), Elvin made two major simplifications from the Linda
model:

1) the Linda in() operator requires tuplespace-wide synchronisation.
   Elvin effectively only implements out(), and rd(), removing this
   difficulty.

2) Linda's storage requirements mean that in practice the model is
   diluted by engineering concerns for management of storage.
   publishing Usenet into pure-Linda is not feasible, for example.

these choices make wide-area Elvin far more practical.

additionally, they have pushed us more into a model of prolific
publication which i believe has intrinsic merit as a way of
constructing systems compared with Linda's more coupled approach.


having said that, there're obviously uses for persistent state.
persistence in a data-oriented model like Linda is simple.  Elvin is
more challenging: it is both message-oriented (leading to mailboxes)
and data-oriented (leading to ...?)


it has long been my hope/belief that correlation is the real way to do
persistence in Elvin.  in the meantime, i guess we can keep playing
with simpler approaches ...




d






From Matthew.Phillips at dsto.defence.gov.au  Fri Oct 19 09:26:22 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:39 2003
Subject: Presence specification draft 0.3.1
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB4E@salex005.dsto.defence.gov.au>

The "Status" field added in 0.3 is missing from the examples: the following
is a corrected version.

Matthew.

 <> 

Title: Elvin Presence Protocol








Elvin
Presence Protocol

Matthew Phillips


Draft 0.3.1 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 19/10/2001)

 

Contents

 TOC \o "2-2" \h \z \t "Heading
1,1" Notes About This Document  PAGEREF _Toc528115311 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310031000000


1      Aim    PAGEREF _Toc528115312 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310032000000


2        Requirements   PAGEREF _Toc528115313 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310033000000


3        Specification   PAGEREF _Toc528115314 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310034000000


3.1       User
Identity   PAGEREF _Toc528115315 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310035000000


3.2       Groups.  PAGEREF _Toc528115316 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310036000000


3.3            Operation   PAGEREF _Toc528115317 \h 3
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310037000000


3.4            Example
Exchange   PAGEREF _Toc528115318 \h 3
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310038000000


3.5            Example
With Multiple Groups   PAGEREF _Toc528115319 \h 4
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300310039000000


3.6            Presence
Request Fields   PAGEREF _Toc528115320 \h 6
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320030000000


3.7            Presence
Info Fields   PAGEREF _Toc528115321 \h 6
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320031000000


3.8            Handling
Conflicting Presence-Info Responses   PAGEREF _Toc528115322 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320032000000


3.9       Notes.  PAGEREF _Toc528115323 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320033000000


4        References   PAGEREF _Toc528115324 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320034000000


4.1       Other
Presence Protocols   PAGEREF _Toc528115325 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500320038003100310035003300320035000000


 


Notes About This Document

The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in IETF RFC 2119.

Changes to the previous 0.2 draft specification are highlighted in green.

1        
Aim

The aim of the presence protocol is to provide a simple
and flexible means for Elvin users to communicate their presence online and
publish information they may wish to have known about themselves.

2        
Requirements

Presence services are already provided to a greater or
lesser extent by a number of applications, including ‘finger’, CoffeeBiff and
various Instant Messaging (IM) clients such as Jabber and ICQ.  The primary reasons for, and advantages of,
providing presence information via the Elvin presence protocol are:


·       
Does not require centralised, persistent state.


·       
Simple and thus easy to support.


·       
Separate, but complementary to, ticker messaging.


·       
Extensible.

3        
Specification

This section describes the protocol, including the
operations between clients and the format of the presence notifications.

3.1       
User Identity

The presence protocol assumes that users are identified by
a combination of name and domain, both of which are
case-insensitive strings containing any character except ‘@’.  The combination of name@domain
forms a unique user ID for the user in ‘presence space’ in the same
manner as an email address.

3.2       
Groups

A group is a namespace containing a set of online
users.  Every online user will MUST be in at least
one group and may opt to be in several. 
All users within a group will be aware of each other’s presence by
default.  A group can be thought of as a
public, dynamic ‘buddy list’ that is automatically populated with community of
people.  When users want to add people
outside their main group to their buddy list, they have two options: explicitly
add the other user by name, or join the other group.

For example, suppose all the people working in the Frob
Testing Division of Bob’s Frobs Inc, may elect to be in the ‘ftc.bobco’
group.   The manager of FTC might also
elect to be in the ‘management.bobco’ group so they can maintain contact with
the managers of other divisions.

As well as providing a way to partition presence
information into communities, the group concept is the key to scalability of
the presence protocol by making it efficient for clients to subscribe to all
presence info in a group, knowing this won’t bog down the entire online world.

3.3       
Operation

The presence protocol
operates by exchanging two types of notifications:


·       
Presence-Info, and


·       
Presence-Request

Clients use Presence-Info notifications to publish
presence information about themselves, and use Presence-Request to trigger
other clients to generate info notifications.

Clients subscribe to Presence-Request notifications, and
generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up
and when any of the presence information previously published has changed.  A number of fields in Presence-Info are
optional, meaning they may be left out when their values are the same as they
were in the last full notification.

3.4       
Example Exchange

Note: see sections 3.6
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000
 & 3.7
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000
 for definitions of the Presence-Request and
Presence-Info notifications.

Scenario: Zaphod@hitch-hikers is already online.  Frodo@hitch-hikers, starts up a
presence-capable client.  Both are in
the ‘hitch-hikers’ group.

Frodo initially announces
he is online with the following full presence info notification:


    Presence-Info: initial
Presence-Protocol: 1000
             User: Frodo@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Zaphod’s client, being subscribed to presence info in for
the hitch-hikers group, receives the information about Frodo and updates its
registry.

Frodo’s client now populates its registry by:


1.     
Subscribing to presence information for the hitch-hikers group
using the expression:
require (Presence-Info)
&&

    contains (fold-case (Groups), “|hitch-hikers|”)


2.     
Sending a request for presence information about people in the
current group.  The presence request
notification Frodo sends is:

 Presence-Request: cafebabe12345
Presence-Protocol: 1000 
         Reqestor: Frodo@hitch-hikers
           Groups: |hitch-hikers|
            Users: *

All clients in the group, including Zaphod’s, receive the
request since they have subscribed using an expression like:

Require (Presence-Request)
&&
  (contains (fold-case (Groups),
“|hitch-hikers|”) ||
   contains (fold-case (Users),
“|zaphod@hitch-hikers|”))

Zaphod’s client responds with a full presence info
notification tagged with the request ID from Frodo’s message:


    Presence-Info: reply cafebabe12345
Presence-Protocol: 1000
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online (going for coffee at 3pm)
  Status-Duration: 42
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: zticker 3.0
x-Number-Of-Heads: 2

Frodo’s client updates its registry, at which point
Zaphod, Frodo, and any other interested clients are in sync.

Later, when Zaphod decides to go for coffee, he hits the
“Coffee!” button on his client, which sends this partial presence notification:

    Presence-Info: update
Presence-Protocol: 1000
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: unavailable
      Status-Text: Coffee!
  Status-Duration: 0

3.5       
Example
With Multiple Groups

The previous example assumed
Frodo was in a single group.  The
following example (shown
from Frodo’s end
only) illustrates how his client would support Frodo being both in the ‘hitch-hikers’ group and the
‘hobbits’ group.  The key changes from the previous example
are highlighted in bold.

Frodo’s client would
announce he is online with:


    Presence-Info: initial
Presence-Protocol: 1000
             User: Frodo@hitch-hikers
           Groups: |hitch-hikers|hobbits|
           Status: online
      Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups: |BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Frodo’s client subscribes to Presence-Request using this expression:

require (Presence-Request) &&
  contains (fold-case (Groups),
     “|hitch-hikers|”, “|hobbits|”) ||
  contains (fold-case (Users), “|frodo@hitch-hikers|”)







3.6       
Presence Request Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
  
   
   Presence-Request
   
   
   String
   
   
   Marks the notification as a presence request and
   carries a request ID.
   
   
   A random, unique request ID, not longer than 255
   characters, no spaces.  The ID MUST NOT be “initial” or “update”.
   
   
   Always
   
  
  
   
   Presence-Protocol
   
   
   Int32
   
   
   Same as Presence-Info
   
   
    
   
   
   Always
   
  
  
   
   Requestor
   
   
   String
   
   
   The
   username of the person requesting the presence information.
   
   
   A
   username in user@domain
   form.
   
   
   Optional
   
  
  
   
   Groups
   
   
   String
   
   
   Same as Presence-Info Allows a client to
   request status info of all users in a set of groups.
   
   
   A
   set of groups in the same format as Presence-Info or  “*’ when
   the User field contains a specific username.
   The User and Groups fields MUST NOT both be “*”.
   
   
   Always
   
  
  
   
   Users
   
   
   String
   
   
   Allows a client to request status info of a particular
   users Clients
   should respond to requests when the “Users” field matches contains their
   username.
   
   
   A specific usernameA set of usernames delimited by “|” or “*” (any
   user).
   Eg “|frodo@home|bob@bobco”.
   The User and
   Groups fields MUST NOT both be “*”.  
   
   
   Always
   
  
 


 

3.7       
Presence Info Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
 
 
  
  Presence-Info
  
  
  String
  
  
  Marks this as a presence info notification and specifies
  its subtype
  
  
  
·       
  “initial”: Full info, with all fields that the client
  supports populated.  Generated when
  the client starts and broadcasts initial presence info.
  
·       
  “reply  request_id”:
  Full info (all fields that the client supports are populated) in response to
  a Presence-Request with ID request_id.
  
·       
  “update”: Partial info, with only the optional fields
  that have changed since last update included.  Generated when presence data (eg Status-Text) changes.
  
  

  Always
  
 
 
  
  Presence-Protocol
  
  
  Int32
  
  
  The version of the presence protocol that is used in
  this notification.
  
  
   major_version
  * 1000 + minor_version.  Eg.
  2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for
  major/minor versions apply: major version number changes indicate
  incompatible changes to the protocol, minor number increments indicate
  backward-compatible changes to the protocol.
  
  
  Always
  
 
 
  
  User
  
  
  String
  
  
  The user’s username.
  
  
  Any username: eg “mpp@dsto”, “bob@bobco”, etc.
  
  
  Always
  
 
 
  
  Groups
  
  
  String
  
  
  The groups the user is a member of.
  
  
  A set of group names separated by ‘|’.
  For example “|dsto|quake heroes|”.
  Note that the preceding and trailing ‘|’s allow clients to easily use the
  ‘contains’ function to test for particular groups without having to handle
  three cases (ie where the group is at the beginning, middle and end of the
  list).
  
  
  Always
  
 
 
  
  Status
  
  
  String
  
  
  The
  status of the user.
  
  
  
·       
  “online”: the user is online and ready to receive
  messages.
  
·       
  “unavailable”: the user is not currently viewing
  messages (eg away from desk).
  
·       
  “unavailable?”: the client has automatically set
  this status based on activity (keystroke/mouse) monitoring, so this is an educated guess.
  
·       
   “offline”: the user is not
  currently connected.  This is usually
  sent as the status when a presence client disconnects.
  
·       
   “coffee”: the user is on a
  coffee break.
  The
  “online”, “offline” and “unavailable” settings SHOULD be taken into account by the client when merging
  conflicting notifications: see section  REF _Ref527966988
  \r \h 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for a discussion on this.
  
  

  Optional
  
 
 
  
  Status-Text
  
  
  String
  
  
  Text
  describing the status of the user.
  
  
  Any string intended to be displayed as the current status eg
  “Online: but will be away this afternoon”.
   
  
  
  Optional: required when the Status field is present
  
 
 
  
  Status-Duration
  
  
  Int32
  
  
  The amount of time (in seconds) that the current status has
  been in effect.  This is a relative duration rather than an absolute time since the
  status was set to
  avoid the perennial problems with inaccurate clocks and time zones.
  
  
  Any integer >= 0. 
  Undefined behaviour if anyone holds the same status longer than 136
  years ;) (232 seconds)
  
  
  Optional: required when Status field is present
  
 
 
  
  Chat-Groups
  
  
  String
  
  
  The set of chat groups the user is subscribed to.
  
  
  Eg. “|Chat|ticker-dev|”
  
  
  Optional
  
 
 
  
  News-Groups
  
  
  String
  
  
  The set of news groups the user is subscribed to.
  
  
  Eg. “|BreakingStories|Slashdot|”
  
  
  Optional
  
 
 
  
  Ticker-Client
  
  
  String
  
  
  The ticker client the user is running
  
  
  A ticker client name and version eg “sticker 2.0.1”,
  “xtickertape 2.0a”.  A missing value
  indicates the user is not running a ticker client.  Users that are running ticker that don’t wish the type of
  client to be known should use “generic”.
  
  
  Optional
  
 










3.8       
Handling
Conflicting Presence-Info Responses

Clients SHOULD handle the situation where multiple Presence-Info responses
are received for single user by using the precedence of the Status fields.  For example, in the case where a user is running two clients on
two hosts, one of which is listing the user as “unavailable?”, the other which lists the
user as “online”, Presence-Requests
will generate two responses.  In this
case, clients SHOULD clearly give precedence to the information in the “online” response over the “inactive?”.  The order of precedence is 
“online”, “unavailable”, “unavailable?” and “offline”, with other statuses being
equal bottom of the order.

3.9       
Notes


·       
Presence-Info: the values of this field have been
designed so that clients can easily discern the derivation of updates if they
wish (for efficiency or otherwise). 
However, clients are not required to distinguish between the different
types of Status-Info notification: simply updating a registry with the new data
in any Presence-Info notification is sufficient, so long as missing optional
fields are handled.

Note that one possible efficiency enabled by this approach is the ability to
opt out of redundant “reply” updates in response to a Presence-Request from
other clients, using the expression Status-Info != “reply”.  The other obvious way to mark replies to
status requests -- with a separate “In-Reply-To” field -- makes this difficult,
since !require
(In-Reply-To) can’t be used to create the same effect due to the
tri-state logic used in the Elvin subscription language.


·       
Presence-Protocol: this is designed so that clients can
subscribe to known protocol sets eg “Protocol-Version >= 1000 &&
Protocol-Version < 3000” picks up any 1.x or 2.x protocol
notifications.


·       
It is assumed that, if the user is running a ticker
client, then they are subscribed to their ‘personal’ chat group with the same
name as their user ID ie “user@domain”. 
This convention makes it obvious how to send a ticker message to someone
visible via the presence system.


·       
Non-standard fields should use the “x-” naming
convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to
display the non-standard fields.


·       
Treating
usernames or
groups as case-sensitive
runs the risk of
people not seeing each other because they got the case wrong eg I look for
‘bob@bobco’ and fail to see him because he is really ‘Bob@BobCo’.


·       
Requestor
field: this was
initially intended
to allow clients to respond differently depending on the requestor, eg subscriptions to some groups might be
hidden except to certain people.  But since any client can listen
in to the replies, it
would not be a particularly useful way of hiding information (using
the security API’s would make more sense).  It
is left in the
specification but
made optional.

4        
References

4.1       
Other Presence Protocols

Thanks to David Arnold for providing the initial set of
links that these references are based on.

4.1.1       
Simple General Awareness Protocol (SGAP)

A Lotus-sponsored IETF
Internet Draft, which expired on May 98. 
It’s not clear if this is still a live project.  Specification talks mainly about
client/server interactions and message formats.  Seems to offer little wisdom for this specification.

Also see Lotus
Research Page for more information.

4.1.2       
Instant Messaging and Presence Protocol (IMPP)

Uses presence information messages (MIME type
message/cpim) that contain an XML presence info ‘payload’.

Example payload (from IMPP
internet draft):

                         open                     away                       im:shingo@jp.fujitsu.com       I'll be in Tokyo tomorrow                          open              mailto:shingo@jp.fujitsu.com           

 

The main wisdom to be gained here is that the presence
info is divided into one or more contact tuples, which describe the users’
status in a particular online medium. 
In the example, the user is saying they have both Instant Messaging and
email contacts, but are not online for IM. 
The addition of the note to the IM tuple presumably informs interested
parties that the person will be available for chat the next day.  The Status-Text field of this protocol gives
some of this functionality, but we are really assuming that ticker is the main
messaging method.  Email addresses and other
info can be supplied as an “x-” field.

For more info see IMPP charter page,
IMPP main page, IMPP working group pages and
Lotus
Research.

4.1.3       
Jabber

Jabber is an IM/presence service built from a series of
federated servers.  The protocol is open
and there are a number of open-source clients. 
A free trialware server for up to 100 users is available, but a
commercial license is needed for larger numbers of users.

The XML-based Jabber protocol
includes a presence message type. 
Example (from protocol page):

      Stay but a little, I will come again.    away   

The distinction between
‘show’ and ‘status’ is interesting. 
Status is user-readable text and is used in the same way the protocol in
this document.  ‘Show’ can be:



 
  

  chat
  
  
  The client is available for immediate contact.
  
 
 
  
  away
  
  
  The client is online, but is momentarily away (e.g., at lunch or a
  meeting).
  
 
 
  
  xa
  
  
  The client is online, but has been inactive for a long time.
  
 
 
  
  dnd
  
  
  The client is in Do Not Disturb mode.
  
 


The Elvin presence protocol
currently overloads show and status into the ‘Status’ field eg
“Unavailable (at meeting in rm 56)” is the same as Jabber show = “away” +
status = “at meeting in rm 56”.  We may
want to consider following the Jabber example.

Jabber also has an “iq” message format can be used to
exchange extended information.

See home page, main commercial page, Jabber Central news page

4.1.4       
ICQ

The ICQ
v5 protocol allows a range of, non-extensible (?) information about a user
to be published using the CMD_META_USER message such as name, phone, age, city
etc.  This sort of information could be
accommodated by the Elvin presence protocol using x-Name, x-Phone etc.

See
ICQ protocol site.








From lawley at dstc.edu.au  Mon Oct 22 16:34:42 2001
From: lawley at dstc.edu.au (Michael Lawley)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] presence proxy agent
In-Reply-To: <200110170652.f9H6qK403782@xevious.dstc.monash.edu.au>
Message-ID: <200110220634.f9M6Ygc27395@piglet.dstc.edu.au>



One of the things I had always wanted to do was implement a generic
form of persistence where quench events triggered event replay.

Of course there are a number of problems with this including:

 * you don't get quench change when a new subsumed subscription is added

 * existing clients will see the 'replayed' notif which would be
   'bad' for non-presence/coffeebiff-like protocols eg ticker
   [This was even part of my original desire for nested notifs back
    when DSTC lived in the Gehrmann Labs.]

|v|					"analog - the new digital"

--
	Michael Lawley,			http://purl.org/NET/lawley
	Scientician.







From Matthew.Phillips at dsto.defence.gov.au  Wed Oct 24 12:10:51 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Presence specification draft 0.3.1
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EB67@salex005.dsto.defence.gov.au>


So, any comments on the 0.3.1 Presence spec?

I'm planning to implement the spec in Sticker 2 in the next week or so -- if
there's interest I can also make the implementation available as a
standalone test app as well.

Matthew.

> -----Original Message-----
> From: Phillips, Matthew [mailto:Matthew.Phillips@dsto.defence.gov.au]
> Sent: Friday, 19 October 2001 8:49 AM
> To: ticker-dev (E-mail)
> Subject: [ticker-dev] Presence specification draft 0.3.1
> 
> 
> The "Status" field added in 0.3 is missing from the examples: 
> the following
> is a corrected version.
> 
> Matthew.
> 
>  <> 
> 



From Martin.Wanicki at Australia.Boeing.com  Mon Nov  5 10:16:06 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A5798D8@xch-bne-01.bal.bna.boeing.com>


Dear ticker-dev(ers) 

Been thinking a lot about this now that I've had a chance to implement this
in a little winblows & com based 
presence app, and have these *Humble* opinions to add.

My comments and Ideas are only concerning the Status & status-text fields
and their logic and use.

Firstly, the status field should not be a string, or else why do we have a
status text field.
I understand the concept of making it readable *but* its only readable in
English :-) 
Sooooo to that end I put forward that the status field should be a machine
readable value (a number)
that has the same meaning in any language.

The status-text field should be used to describe the reason for the status
change.
This leads me to my next point.. the actual status states...

Online.. yep this sounds good on the surface but what happens immediately
after an online message ?
I would suggest, an available/unavailable/off-line/coffee... etc. would be
the next logical event which would almost
immediately overwrite the online event. 
So lets drop it, online can be derived by anything that is not a off-line
event.

This leaves us with an "online" status change and an "off-line" status
change with "online"  being one of available/unavailable

I do see possible requirements for some more defined status-changes so to
that end suggest we either keep it simple
and have single status change with the description explaining the status
*OR* we have a defined enumerated type
that explains the reason for the status change. 

Sooooo here's my suggestion.

Status becomes a number.
            Negative One  (-1)			= off-line
	Zero	         ( 0 )			= Available
	Positive Non-Zero	(1..???) 	= some "Unavailable" status
event	

Lets define some of the unavailable events as part of the standard
and provide user-defined unavailable status events at, say, anything over
100 

here are a few to start with ..  

				Appointment|Lunch|Coffee|....more.....

Hey, by defining these constant values we also begin to facilitate language
independence!  :-)
	

What follows are just some other implementation ideas thrown open to debate 

	Person is Available    (human selected option)
	Person is Unavailable  (human selected option)
	No Client activity for X mins  - configurable (machine selected
option)

With just these three, consider the following example ...

Client_1 application starts and the client software interrogates
configuration data to decide if the person
wants to be available by default or not then the client emits an
available/unavailable message as appropriate.

Receiving Client_2 can interpret this non-negative value as an online event
and the maintain their registry according to the actual value & the
status-text (if supplied)

Assuming Client_1 sent an "Available" and then the person operating Client_1
steps away from their computer for a while,
Client_1 could emit a No_Client_Activity status is an implied unavailable
status according to some configurable rule

Client_2 would be aware the Client_1 is on the network and that the person
operating Client_1 may eventually see any messages posted to them.

Ok thats it for this one, please excuse the rambling nature of my
suggestions, I *think* I have it all down from 
thoughts I had over the weekend.

Cheers

Martin



















From Martin.Wanicki at Australia.Boeing.com  Mon Nov  5 10:53:01 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Elvin presence specification extension ?
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A579956@xch-bne-01.bal.bna.boeing.com>


Dear All


I had some ideas about an autoresponder providing information about the
human operating the client as an extension of the presence protocol.

The basics are that rather that having to maintain a central database of,
say phone numbers, if a client is configured
with details about the person, and is set to respond to "finger" type
queries than it should. But we need a spec and protocol to ratify this so
that all clients exporting this functionality have the same interface.

I'm imagining getting a message dialog saying something like "foo" has
requested personal information - do you wish to provide it"

The way this could work with the presence protocol is that a client could be
configured to automatically respond to people in your group but to prompt
you if a request comes from outside the group or completely ignore requests
not from your group or from anywhere.

There should always be a reply, even if it's just to say the request was
denied.

I'm suggesting the contents of the provision of information be completely at
the users discretion.
but the notification format of the response be defined

There's some issues that I'm not too clear on...

Do we closely couple this with the presence protocol or do we allow ticker
queries like

	Info bill@hq? 

and if we allow this type of query do we also map the responses into an
overloaded ticker notification spec??

so the coupling to spec needs some discussion.

Assuming a close coupling with the presence spec.

The notification format for a response begins with the all the fields of a
presence Info notification with the exception of status change,text and
duration.

First we add the type "Info" to the contents of Presence-Info attribute...
if we are replying with Info and
the type 'Info-denied' if we are not replying with Info.   The subscriptions
are obvious.
If the type is "info" then..
	User becomes whatever name the user want to provide
	Next we add "User-Phone" for ....(bet you cant guess :-) Populated &
mandatory 
	Then we add "User-Email" for (once again...)	Populated &
mandatory 

the rest of the data is entirely optional, maybe we can use some sort of
e-card in a mime field or we just define optional attribute names..
here's some ideas and a start - but this is not a definitive list ..

Then we add "User-Address" 		optional !	
Then we add "User-Sex" ..  		optional !
Then we add "User-Age" ..  		optional !
Then we add "User-Age" ..  		optional !


This idea really just came out of the phone bot that bill wrote for dstc.
I wrote an ldap lookup bot that handles a variety of lookups (phone, email,
..etc) 
Then I thought about a group of people not members of the same organization,
that interact 
regularly & freely share their location, email and phone number information.

I also thought about the notion that people within an organization can be
responsible for maintaining the availability of "current"
information about them. 

Over to the tickerdev crew ... your thoughts ?? 


Cheers

Martin 








Retain 



From arnold at dstc.monash.edu.au  Mon Nov  5 16:11:08 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Elvin presence specification draft
In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690A5798D8@xch-bne-01.bal.bna.boeing.com>
Message-ID: <200111050611.fA56BAc27627@xevious.dstc.monash.edu.au>


-->"Martin" == Wanicki, Martin  writes:

  Martin> Firstly, the status field should not be a string, or else
  Martin> why do we have a status text field. I understand the concept
  Martin> of making it readable *but* its only readable in English :-)
  Martin> Sooooo to that end I put forward that the status field
  Martin> should be a machine readable value (a number) that has the
  Martin> same meaning in any language.

i don't really care either way here.  both are defined patterns of
bits.  if one particular language group can benefit from simpler
recognition of that bit pattern, that's fine with me.  but not having
that is also ok if there's some benefit.


  Martin> This leaves us with an "online" status change and an
  Martin> "off-line" status change with "online" being one of
  Martin> available/unavailable

if you rename "available" to "online" here, don't you have the same
thing?  


  Martin> Status becomes a number. Negative One (-1) = off-line Zero (
  Martin> 0 ) = Available Positive Non-Zero (1..???)  = some
  Martin> "Unavailable" status event

what is the expected benefit of having machine-readable variations on
"unavailable"?

  Martin> Appointment|Lunch|Coffee|....more.....

the only thing i can see being actually useful, from a
machine-readable point of view, is an expected duration of the lack of
availability.

i don't see any benefit in having different codes for "meeting" vs
"lunch" (for example).


some thoughts ...


for my usage, "offline" is useless.  i'm never (or so infrequently as
to be insignificant) offline.  one or more of my sessions (and
therefore presence tools) is running at all times.

i'm happy that some people have a different usage pattern which might
make this value meaningful, but i'm not sure i want my client programs
sending an "offline" by default when they exit, because it's not
necessarily true.

i think explicitly set textual status messages, with an explicit
indication of "available/online" or "unavailable" are useful.  i will
do that at least some of the time.

i think automatic "unavailable?" and "available?" status values are
useful.  i am very likely to walk away-from/up-to my machine and
forget to set the status text.  

imagine that at midday, you want my status, and get

    last status:    in meeting @ 10:55am
    last activity:  11:54am

that would be kinda useful.  you can reasonably guess that i'm back
from my meeting but haven't set my status yet.  not that we'd
necessarily want all presence tools to have to monitor key/mouse
activity.  it could also be construed as an invasion of privacy ;-)


i don't know what's best here.  i need to play/think more :-(





d



From arnold at dstc.monash.edu.au  Mon Nov  5 16:21:47 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Elvin presence specification extension ?
In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690A579956@xch-bne-01.bal.bna.boeing.com>
Message-ID: <200111050621.fA56Lnc27717@xevious.dstc.monash.edu.au>


-->"Martin" == Wanicki, Martin  writes:

  Martin> I had some ideas about an autoresponder providing
  Martin> information about the human operating the client as an
  Martin> extension of the presence protocol.

  Martin> The basics are that rather that having to maintain a central
  Martin> database of, say phone numbers, if a client is configured
  Martin> with details about the person, and is set to respond to
  Martin> "finger" type queries than it should. But we need a spec and
  Martin> protocol to ratify this so that all clients exporting this
  Martin> functionality have the same interface.

Matthew's spec proposed optional fields that the client could choose
to make public.

  Martin> I'm imagining getting a message dialog saying something like
  Martin> "foo" has requested personal information - do you wish to
  Martin> provide it"

problem with this is that over the weekend, i could get several
hundred of these on my work screen, which i've actually dealt with at
home.  i think dialogs like this make for simple DoS attacks ...

  Martin> The way this could work with the presence protocol is that a
  Martin> client could be configured to automatically respond to
  Martin> people in your group but to prompt you if a request comes
  Martin> from outside the group or completely ignore requests not
  Martin> from your group or from anywhere.

configuring a list of groups/users who are allowed to get this info
without bothering me seems sensible.  

  Martin> There should always be a reply, even if it's just to say the
  Martin> request was denied.

in Matthew's spec, this is just the normal Presence-Info reply.

  Martin> I'm suggesting the contents of the provision of information
  Martin> be completely at the users discretion. but the notification
  Martin> format of the response be defined

i guess we could agree on a naming scheme for some common fields, but
the idea was that any field could be added, so long as it had an `X-'
prefix.  your user agent can strip that for display, like
`X-Work-Phone' becomes `Work-Phone'.

but i guess i can see that people might like to have this agreed, and
internationalised, etc, for sexier display.

  Martin> Over to the tickerdev crew ... your thoughts ??

i'd like to get the base presence spec sorted, with the extension
mechanism included, which i think supports this as is.  perhaps then
we can debate a revision which includes a set of standard attribute
names for common personal info (phone, mobile, fax, whatever) ?





d



From Martin.Wanicki at Australia.Boeing.com  Mon Nov  5 16:35:34 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:39 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A579CF9@xch-bne-01.bal.bna.boeing.com>


David may have said...	
> ----------
> From: 	David Arnold[SMTP:arnold@dstc.monash.edu.au]
> Reply To: 	davida@pobox.com
> Sent: 	Monday, November 05, 2001 4:11 PM
> To: 	ticker-dev (E-mail)
> Subject: 	Re: [ticker-dev] Elvin presence specification draft 
> 
> -->"Martin" == Wanicki, Martin 
> writes:
> 
>   Martin> Firstly, the status field should not be a string, or else
>   Martin> why do we have a status text field. I understand the concept
>   Martin> of making it readable *but* its only readable in English :-)
>   Martin> Sooooo to that end I put forward that the status field
>   Martin> should be a machine readable value (a number) that has the
>   Martin> same meaning in any language.
> 
David> i don't really care either way here.  both are defined patterns of
> David> bits.  if one particular language group can benefit from simpler
> David> recognition of that bit pattern, that's fine with me.  but not
> having
> David> that is also ok if there's some benefit.
well it is if we have some defined status enums .. see later


>   Martin> This leaves us with an "online" status change and an
>   Martin> "off-line" status change with "online" being one of
>   Martin> available/unavailable
> 
> David> if you rename "available" to "online" here, don't you have the same
> David> thing?  
its only vice versa renamning "online" to "available" because there may 
be many kinds of available all of which mean online as well 


>   Martin> Status becomes a number. Negative One (-1) = off-line Zero (
>   Martin> 0 ) = Available Positive Non-Zero (1..???)  = some
>   Martin> "Unavailable" status event
> 
> David> what is the expected benefit of having machine-readable variations
> on
> David> "unavailable"?
well its started out to facilitate the "Coffee" status, but if the protocal
is to facilitate "Coffee" why stop there?
There are many common reasons for unavailability and if we capture the vast
majority of "common" ones we
facilitate a language independance and a set client behaviour.

>   Martin> Appointment|Lunch|Coffee|....more.....
> 
> David> the only thing i can see being actually useful, from a
> David> machine-readable point of view, is an expected duration of the lack
> of
> David> availability.
> 
that currently doesnt exist in the protocol, only an elapsed time, which to
me is ok cause an 
expected duration is only a guess but when one gets back to their client and
changes the status, the status actually represents activity
where unavailable represents inactivity (kind of)


> David> i don't see any benefit in having different codes for "meeting" vs
> David> "lunch" (for example).
refer to the "Coffee" explanation above..


> David> some thoughts ...
> 
> 
> David> for my usage, "offline" is useless.  i'm never (or so infrequently
> as
> David> to be insignificant) offline.  one or more of my sessions (and
> David> therefore presence tools) is running at all times.
Perhaps from you.. but "To" you isnt it useful to know, say, Bill is
offline? versus unavailable.


> David> i'm happy that some people have a different usage pattern which
> might
> David> make this value meaningful, but i'm not sure i want my client
> programs
> David> sending an "offline" by default when they exit, because it's not
> David> necessarily true.
> 
> David> i think explicitly set textual status messages, with an explicit
> David> indication of "available/online" or "unavailable" are useful.  i
> will
> David> do that at least some of the time.
Agreed

> David> i think automatic "unavailable?" and "available?" status values are
> David> useful.  i am very likely to walk away-from/up-to my machine and
> David> forget to set the status text.  
also agree..

> David> imagine that at midday, you want my status, and get
> 
> David>     last status:    in meeting @ 10:55am
> David>     last activity:  11:54am
> 
> David> that would be kinda useful.  you can reasonably guess that i'm back
> David> from my meeting but haven't set my status yet.  not that we'd
> David> necessarily want all presence tools to have to monitor key/mouse
> David> activity.  it could also be construed as an invasion of privacy ;-)
Agree whole hartedly, one of the reasons I support the notion on unavailable
until notified otherwise..

> David> i don't know what's best here.  i need to play/think more :-(
:-)


Martin



From Martin.Wanicki at Australia.Boeing.com  Mon Nov  5 16:38:13 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification extension ?
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A579D00@xch-bne-01.bal.bna.boeing.com>


So I have at lease one partial agreement that the concept has merit, and
will reduce the need for a centralised phone-bot, email-bot ..etc ??



> ----------
> From: 	David Arnold[SMTP:arnold@dstc.monash.edu.au]
> Reply To: 	davida@pobox.com
> Sent: 	Monday, November 05, 2001 4:21 PM
> To: 	ticker-dev (E-mail)
> Subject: 	Re: [ticker-dev] Elvin presence specification extension ? 
> 
> -->"Martin" == Wanicki, Martin 
> writes:
> 
>   Martin> I had some ideas about an autoresponder providing
>   Martin> information about the human operating the client as an
>   Martin> extension of the presence protocol.
> 
>   Martin> The basics are that rather that having to maintain a central
>   Martin> database of, say phone numbers, if a client is configured
>   Martin> with details about the person, and is set to respond to
>   Martin> "finger" type queries than it should. But we need a spec and
>   Martin> protocol to ratify this so that all clients exporting this
>   Martin> functionality have the same interface.
> 
> Matthew's spec proposed optional fields that the client could choose
> to make public.
> 
>   Martin> I'm imagining getting a message dialog saying something like
>   Martin> "foo" has requested personal information - do you wish to
>   Martin> provide it"
> 
> problem with this is that over the weekend, i could get several
> hundred of these on my work screen, which i've actually dealt with at
> home.  i think dialogs like this make for simple DoS attacks ...
> 
>   Martin> The way this could work with the presence protocol is that a
>   Martin> client could be configured to automatically respond to
>   Martin> people in your group but to prompt you if a request comes
>   Martin> from outside the group or completely ignore requests not
>   Martin> from your group or from anywhere.
> 
> configuring a list of groups/users who are allowed to get this info
> without bothering me seems sensible.  
> 
>   Martin> There should always be a reply, even if it's just to say the
>   Martin> request was denied.
> 
> in Matthew's spec, this is just the normal Presence-Info reply.
> 
>   Martin> I'm suggesting the contents of the provision of information
>   Martin> be completely at the users discretion. but the notification
>   Martin> format of the response be defined
> 
> i guess we could agree on a naming scheme for some common fields, but
> the idea was that any field could be added, so long as it had an `X-'
> prefix.  your user agent can strip that for display, like
> `X-Work-Phone' becomes `Work-Phone'.
> 
> but i guess i can see that people might like to have this agreed, and
> internationalised, etc, for sexier display.
> 
>   Martin> Over to the tickerdev crew ... your thoughts ??
> 
> i'd like to get the base presence spec sorted, with the extension
> mechanism included, which i think supports this as is.  perhaps then
> we can debate a revision which includes a set of standard attribute
> names for common personal info (phone, mobile, fax, whatever) ?
> 
> 
> 
> 
> 
> d
> 



From Matthew.Phillips at dsto.defence.gov.au  Tue Nov  6 10:25:07 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBA5@salex005.dsto.defence.gov.au>


Replies to David and Martin.  I would have liked to spend more time on this
reply, but I've got my hands full at the moment.

>   Martin> Firstly, the status field should not be a string, or else
>   Martin> why do we have a status text field. I understand the concept
>   Martin> of making it readable *but* its only readable in English :-)
>   Martin> Sooooo to that end I put forward that the status field
>   Martin> should be a machine readable value (a number) that has the
>   Martin> same meaning in any language.
> 
> i don't really care either way here.  both are defined patterns of
> bits.  if one particular language group can benefit from simpler
> recognition of that bit pattern, that's fine with me.  but not having
> that is also ok if there's some benefit.

I with David here, you might as well choose a representation that is
meaningful to _someone_

>   Martin> This leaves us with an "online" status change and an
>   Martin> "off-line" status change with "online" being one of
>   Martin> available/unavailable
> 
> if you rename "available" to "online" here, don't you have the same
> thing?  

There is no "available" status, just "online"

>   Martin> Appointment|Lunch|Coffee|....more.....
> 
> the only thing i can see being actually useful, from a
> machine-readable point of view, is an expected duration of the lack of
> availability.
> 
> i don't see any benefit in having different codes for "meeting" vs
> "lunch" (for example).

The reason for having a standard meaning for Status = 'online',
'unavailable' and 'offline' is so that clients can interpret them - for
example warn you when you're going to send a message to someone that is
'unavailable'.  And as far as the client is concerned 'Appointment', 'Lunch'
and 'Coffee' are just as unavailable as anything else.  

> for my usage, "offline" is useless.  i'm never (or so infrequently as
> to be insignificant) offline.  one or more of my sessions (and
> therefore presence tools) is running at all times.

Yes, offline is a bit of a problem, especially when you're running multiple
clients where one sends offline: how do the other people know you're
offline?  In fact it's the same problem when you're running two clients and
then one sets your status to 'unavailable?'  You should still be marked
'online', but most clients would 'downgraded' you to unavailable. Possibly
the 'online' client could notice this and send an update, but this could
happen out of order.  More thought required...

Matthew.



From Matthew.Phillips at dsto.defence.gov.au  Tue Nov  6 13:05:16 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBA8@salex005.dsto.defence.gov.au>


> Folks,
> 
> Reply to Matthew's comments..
> 
> > >   Martin> Firstly, the status field should not be a 
> string, or else
> > >   Martin> why do we have a status text field. I 
> understand the concept
> > >   Martin> of making it readable *but* its only readable 
> in English :-)
> > >   Martin> Sooooo to that end I put forward that the status field
> > >   Martin> should be a machine readable value (a number) 
> that has the
> > >   Martin> same meaning in any language.
> > > 
> > > i don't really care either way here.  both are defined patterns of
> > > bits.  if one particular language group can benefit from simpler
> > > recognition of that bit pattern, that's fine with me.  
> but not having
> > > that is also ok if there's some benefit.
> > 
> >I with David here, you might as well choose a representation that is
> >meaningful to _someone_
> 
> If status is an integer it facilitates extension of the 
> protocol without
> re-hacking all clients
> the values I chose (and have since thought more about and 
> re-chosen) were
> for this reason 
> 	A positive number - regardless of what it is an 
> unavailable event 
> 	An "offline" event is never going to be anything else 
> so 0 is fine
> (yes, I've switched available and offline)
> 	An "available" event, although hardly likely to be 
> anything else,
> may in some point in the 
> 		furure require more granularity, so it can fit into the
> negative number domain. 
> 
> Clients need only to interperet them as   ( negative || zero 
> || positive )
> or clients can choose the more granular interperetations in 
> the ranges of
> ([-maxint .. -1]  || [0] || [1..maxint])
> this gives us scaleability without making older clients redundant.

Yes, but I can't see Status needing other values: you are either online,
unavailable (but runnning a client) or offline entirely.  If we _do_ need to
extend it eg to formally indicate 'temporarily' offline, we could easily do
this using something like 'offline temporary'.

I had forgotten about the standard 'coffee' status, and I can see now where
you're coming from: 'coffee' should be Status = "unavailable" and
Status-Text = "Coffee".  I actually put this in as a special case as a way
to allow CoffeBiff to be done via presence, and I can't any other special
cases creeping in.

> So at the very least, I suggest we keep the status to the basic three
> call them what you may, I like "available"|"unavailable"|"offline"
> I'd be happier if we did use numbers because I like the 
> option of being able
> to use the granularity 
> of the ranges to extend the meaning and not rely on the 
> status text at all,
> but this is not imperative 
> to the ratification of this spec, just something I percieve 
> as useful, and
> scaleable.

I am of the belief that you should be able to look at a notification and get
an idea, a priori, of what it means.  So using coded numbers for concepts
that aren't numeric worries me.  I agree with your scalability concern
though: perhaps we should allow clients to postfix extra info to Status, eg
the 'offline temporary' idea?  This would allow future 'subclasses' of the
standard three states.

Cheers,

Matt.



From Martin.Wanicki at Australia.Boeing.com  Tue Nov  6 13:33:06 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A609982@xch-bne-01.bal.bna.boeing.com>


I'll let this stew for a while, and see what others may have to say:-)

Regarding multiple clients using the same user@domain what did you think
about the offline strategy ??

I'm thinking that a status request is very much a thing you do when you
first come on line.
after that one receives and emits notifications for status changes. 
I think it may be reasonable to imply that an offline event is a kind of
status request for clients using the same name@domain pair, your thoughts?

With the heirarchy (for want of a better word) of availability notifications
I'm thinking available beats unavailable at all times.
So another client would only show a person as unavailable when the last of
their clients emits an unavailable?
If this is reasonable then what remains is deciding what type of available
beats another, or should it be time-based.
This, by the way, was another reason for the heirarchy within the possible
numbers used to represent "available", smaller numbers "trump" larger
numbers,
but I'll get off that soap box for now :-)

Cheers and goodluck if your betting on the cup.

Martin



> ----------
> From: 	Phillips, Matthew[SMTP:Matthew.Phillips@dsto.defence.gov.au]
> Sent: 	Tuesday, November 06, 2001 12:56 PM
> To: 	'Wanicki, Martin'
> Cc: 	'ticker-dev (E-mail)'
> Subject: 	RE: [ticker-dev] Elvin presence specification draft 
> 
> > Folks,
> > 
> > Reply to Matthew's comments..
> > 
> > > >   Martin> Firstly, the status field should not be a 
> > string, or else
> > > >   Martin> why do we have a status text field. I 
> > understand the concept
> > > >   Martin> of making it readable *but* its only readable 
> > in English :-)
> > > >   Martin> Sooooo to that end I put forward that the status field
> > > >   Martin> should be a machine readable value (a number) 
> > that has the
> > > >   Martin> same meaning in any language.
> > > > 
> > > > i don't really care either way here.  both are defined patterns of
> > > > bits.  if one particular language group can benefit from simpler
> > > > recognition of that bit pattern, that's fine with me.  
> > but not having
> > > > that is also ok if there's some benefit.
> > > 
> > >I with David here, you might as well choose a representation that is
> > >meaningful to _someone_
> > 
> > If status is an integer it facilitates extension of the 
> > protocol without
> > re-hacking all clients
> > the values I chose (and have since thought more about and 
> > re-chosen) were
> > for this reason 
> > 	A positive number - regardless of what it is an 
> > unavailable event 
> > 	An "offline" event is never going to be anything else 
> > so 0 is fine
> > (yes, I've switched available and offline)
> > 	An "available" event, although hardly likely to be 
> > anything else,
> > may in some point in the 
> > 		furure require more granularity, so it can fit into the
> > negative number domain. 
> > 
> > Clients need only to interperet them as   ( negative || zero 
> > || positive )
> > or clients can choose the more granular interperetations in 
> > the ranges of
> > ([-maxint .. -1]  || [0] || [1..maxint])
> > this gives us scaleability without making older clients redundant.
> 
> Yes, but I can't see Status needing other values: you are either online,
> unavailable (but runnning a client) or offline entirely.  If we _do_ need
> to
> extend it eg to formally indicate 'temporarily' offline, we could easily
> do
> this using something like 'offline temporary'.
> 
> I had forgotten about the standard 'coffee' status, and I can see now
> where
> you're coming from: 'coffee' should be Status = "unavailable" and
> Status-Text = "Coffee".  I actually put this in as a special case as a way
> to allow CoffeBiff to be done via presence, and I can't any other special
> cases creeping in.
> 
> > So at the very least, I suggest we keep the status to the basic three
> > call them what you may, I like "available"|"unavailable"|"offline"
> > I'd be happier if we did use numbers because I like the 
> > option of being able
> > to use the granularity 
> > of the ranges to extend the meaning and not rely on the 
> > status text at all,
> > but this is not imperative 
> > to the ratification of this spec, just something I percieve 
> > as useful, and
> > scaleable.
> 
> I am of the belief that you should be able to look at a notification and
> get
> an idea, a priori, of what it means.  So using coded numbers for concepts
> that aren't numeric worries me.  I agree with your scalability concern
> though: perhaps we should allow clients to postfix extra info to Status,
> eg
> the 'offline temporary' idea?  This would allow future 'subclasses' of the
> standard three states.
> 
> Cheers,
> 
> Matt.
> 



From Martin.Wanicki at Australia.Boeing.com  Tue Nov  6 13:43:40 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A60998F@xch-bne-01.bal.bna.boeing.com>


I just remebered a conversation that was had about groups & domains that
kind of contradicts what I said about what trumps what, but I cant remeber
the outcome, so forgive me if what I proposed about using the user@domain
pair to manage this is all wrong ..:-(

> ----------
> From: 	Phillips, Matthew[SMTP:Matthew.Phillips@dsto.defence.gov.au]
> Sent: 	Tuesday, November 06, 2001 12:56 PM
> To: 	'Wanicki, Martin'
> Cc: 	'ticker-dev (E-mail)'
> Subject: 	RE: [ticker-dev] Elvin presence specification draft 
> 
> > Folks,
> > 
> > Reply to Matthew's comments..
> > 
> > > >   Martin> Firstly, the status field should not be a 
> > string, or else
> > > >   Martin> why do we have a status text field. I 
> > understand the concept
> > > >   Martin> of making it readable *but* its only readable 
> > in English :-)
> > > >   Martin> Sooooo to that end I put forward that the status field
> > > >   Martin> should be a machine readable value (a number) 
> > that has the
> > > >   Martin> same meaning in any language.
> > > > 
> > > > i don't really care either way here.  both are defined patterns of
> > > > bits.  if one particular language group can benefit from simpler
> > > > recognition of that bit pattern, that's fine with me.  
> > but not having
> > > > that is also ok if there's some benefit.
> > > 
> > >I with David here, you might as well choose a representation that is
> > >meaningful to _someone_
> > 
> > If status is an integer it facilitates extension of the 
> > protocol without
> > re-hacking all clients
> > the values I chose (and have since thought more about and 
> > re-chosen) were
> > for this reason 
> > 	A positive number - regardless of what it is an 
> > unavailable event 
> > 	An "offline" event is never going to be anything else 
> > so 0 is fine
> > (yes, I've switched available and offline)
> > 	An "available" event, although hardly likely to be 
> > anything else,
> > may in some point in the 
> > 		furure require more granularity, so it can fit into the
> > negative number domain. 
> > 
> > Clients need only to interperet them as   ( negative || zero 
> > || positive )
> > or clients can choose the more granular interperetations in 
> > the ranges of
> > ([-maxint .. -1]  || [0] || [1..maxint])
> > this gives us scaleability without making older clients redundant.
> 
> Yes, but I can't see Status needing other values: you are either online,
> unavailable (but runnning a client) or offline entirely.  If we _do_ need
> to
> extend it eg to formally indicate 'temporarily' offline, we could easily
> do
> this using something like 'offline temporary'.
> 
> I had forgotten about the standard 'coffee' status, and I can see now
> where
> you're coming from: 'coffee' should be Status = "unavailable" and
> Status-Text = "Coffee".  I actually put this in as a special case as a way
> to allow CoffeBiff to be done via presence, and I can't any other special
> cases creeping in.
> 
> > So at the very least, I suggest we keep the status to the basic three
> > call them what you may, I like "available"|"unavailable"|"offline"
> > I'd be happier if we did use numbers because I like the 
> > option of being able
> > to use the granularity 
> > of the ranges to extend the meaning and not rely on the 
> > status text at all,
> > but this is not imperative 
> > to the ratification of this spec, just something I percieve 
> > as useful, and
> > scaleable.
> 
> I am of the belief that you should be able to look at a notification and
> get
> an idea, a priori, of what it means.  So using coded numbers for concepts
> that aren't numeric worries me.  I agree with your scalability concern
> though: perhaps we should allow clients to postfix extra info to Status,
> eg
> the 'offline temporary' idea?  This would allow future 'subclasses' of the
> standard three states.
> 
> Cheers,
> 
> Matt.
> 



From Matthew.Phillips at dsto.defence.gov.au  Tue Nov  6 16:15:03 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: Multiple presence clients for a single user
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBAD@salex005.dsto.defence.gov.au>


Hi all,

I've been doing some cogitating on how to support multiple clients for the
same person without (a) bloating the protocol and (b) without needing
centralised state.

[Martin, sorry for skipping a more personal response, but I think this
addresses some of your thoughts]

Scenario: I run a presence client at work and then go home and run another:
both will initially respond that I am online.  The work client then decides
that I am 'unavailable?' and emits an update, thus making it look like I am
no longer available.

There are 2 solutions to this that don't involve a third party 1) my home
'online' client notices the contradiction and sends a counter-update to set
everyone straight or 2) other clients notice the conflict between my two
clients and handle it by accepting the 'most available' status.   I don't
like 1 because it's messy and would result in status flicking from online to
unavailable to online.  However, option 2 requires that other clients can
tell my two clients apart, since if they can't, they cannot tell that the
'unavailable?' came from a different source to the 'online'.

I have had a think about how a client would implement 2 and it does not seem
hard _if_ there were a 'Client-ID' field on Presence-Info.  Client-ID would
by any random string that remains constant for a given client over a given
session.  Other clients would maintain a registry of User's (user@domain),
each entry of which has an associated list of Presence-Info's, indexed by
Client-ID.  When a new info comes in, the client updates the info for that
User/Client-ID and the client then selects the 'most available' info from
the list and displays that.  Quick-and-dirty clients that don't want to muck
around with this could just show the list of Presence-Info's sorted by User
and then Status.

There are a few other issues, such as clients that crash and don't send an
'offline', but these are solvable.

Comments?




From arnold at dstc.monash.edu.au  Tue Nov  6 17:22:53 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single user
In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EBAD@salex005.dsto.defence.gov.au>
Message-ID: <200111060722.fA67Muc03977@xevious.dstc.monash.edu.au>


-->"Matthew" == Phillips, Matthew  writes:

  Matthew> There are 2 solutions to this that don't involve a third
  Matthew> party 1) my home 'online' client notices the contradiction
  Matthew> and sends a counter-update to set everyone straight or 2)
  Matthew> other clients notice the conflict between my two clients
  Matthew> and handle it by accepting the 'most available' status.

i'm wondering about a potential third method, which involves a few
other changes as well.  i've been trying to clarify the semantics in
my head, and i keep getting the urge to simplify ...

what if:

- there are only two status values: "available" or "unavailable".
  clients do not necessarily send an "unavailable" on exit, but
  perhaps a dialog box like "Set unavailable status?" is useful.

- in the case of multiple presence producers for a user, the one that
  changed most recently is always accepted.  a presence consumer can
  check the duration of the status they already have (if any) against
  the new status and ignore the update if it is older.

- presence *consumers* could downgrade their confidence in an status
  after a period during which they've seen no Presence-Info messages
  from a user.  this is similar in effect to 0.3.1's "unavailable?"

the only loss of functionality i can see is that mouse/key activity
cannot be used by the producer any longer.  one way to regain this
would be to optionally allow producers to downgrade themselves,
flagging their advertised info as potentially inaccurate.


from a user interface perspective, setting a status would now be a
two-part operation: available/unavailable plus the (optional?) message
text.  eg. unavailable + "in meeting until 3pm", or, available +
"dialed in from hotel", etc


this seems like a nicer semantics at the protocol layer to me.  what
do people think?




d



From Matthew.Phillips at dsto.defence.gov.au  Tue Nov  6 18:24:54 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single user
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBAE@salex005.dsto.defence.gov.au>


>  writes:
> 
>   Matthew> There are 2 solutions to this that don't involve a third
>   Matthew> party 1) my home 'online' client notices the contradiction
>   Matthew> and sends a counter-update to set everyone straight or 2)
>   Matthew> other clients notice the conflict between my two clients
>   Matthew> and handle it by accepting the 'most available' status.
> 
> i'm wondering about a potential third method, which involves a few
> other changes as well.  i've been trying to clarify the semantics in
> my head, and i keep getting the urge to simplify ...
> 
> what if:
> <...>

One key point is that the 'unavailable?' status is special because it gets
set automatically, and is not necessarily triggered by a user.  The other
events are user-triggered and imply that the person is really present - they
are more 'positive' in that respect.  However, even though accepting that
the last positive event is authoritative most of the time, it can be broken
fairly easily.  Say I'm moving back and forth between two hosts and two
clients, both of which (correctly) list me as online.  I log out of one
host, setting my status to 'unavailable' as I do so.  I start using host 2,
which already thinks my status is 'online' and does not generate an update -
all clients now think I'm unavailable until I force client 2 to generate
what is, for it, a redundant update.

I also really want to have automatic 'unavailable?' as standard in
full-featured clients because we tend to forget about setting our status.  I
found that, until I added this feature to Sticker, presence status was
fairly useless: I'd dial in on a weekend and find that everyone was 'online'
;)

I absolutely agree with keeping things simple, even at the cost of losing
some cool features. I'd say the spec is too complex if an average hacker
can't put together a halfway useful presence implementation in an hour or
two - I don't think we've crossed that line yet.

Cheers,

Matthew.



From lawley at dstc.edu.au  Tue Nov  6 20:10:02 2001
From: lawley at dstc.edu.au (Michael Lawley)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single user
In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EBAD@salex005.dsto.defence.gov.au>
Message-ID: <200111061010.fA6AA2W22364@piglet.dstc.edu.au>


"Phillips, Matthew" wrote:

> Scenario: I run a presence client at work and then go home and run another:
> both will initially respond that I am online.  The work client then decides
> that I am 'unavailable?' and emits an update, thus making it look like I am
> no longer available.

I think a key issue here is that these are the same user, but different
domains (eg lawless@uq vs lawless@home) and my status is likely to be
different in different domains.  The real question then becomes how does
my status get reported/displayed/visualised in a meaningful and
UI-efficient way.

|v|					"analog - the new digital"

--
	Michael Lawley,			http://purl.org/NET/lawley
	Scientician.







From kas-list at magnetic-ink.dk  Wed Nov  7 00:50:18 2001
From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690A5798D8@xch-bne-01.bal.bna.boeing.com>
Message-ID: <20011106155015.A6152@magnetic-ink.dk>


Martin Wanicki wrote:

> Sooooo here's my suggestion.
> 
> Status becomes a number.
>     Negative One       (-1)     = off-line
>     Zero	         ( 0 )    = Available
>     Positive Non-Zero	 (1..???) = some "Unavailable" status event

I'm sorry Martin, but I do not support your suggestion.

Because of Elvin's subscription language I feel that notifications
should target humans, not applications.  While it might be tedious
to do the initial programming if text parsing is involved, it needs
only be dealt with once, and notifications like 'Status: "Online"'
are more intuitive that 'Status: 1' (who's got the header files or
a reference card available when subscribing?).

I am aware that most, if not all, status subscriptions will be done
by clients apps, but I still believe that programmers should design
their applications as if humans were the subscribers.  In the long
run such an approach will improve the overall usability, IMHO.


  // Klaus

-- 
 ><>°	 vandag, môre, altyd saam



From arnold at dstc.monash.edu.au  Wed Nov  7 07:32:37 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single us er
In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EBAE@salex005.dsto.defence.gov.au>
Message-ID: <200111062132.fA6LWec07908@xevious.dstc.monash.edu.au>


-->"Matthew" == Phillips, Matthew  writes:

  Matthew> One key point is that the 'unavailable?' status is special
  Matthew> because it gets set automatically, and is not necessarily
  Matthew> triggered by a user. 

yep.

  Matthew> The other events are user-triggered and imply that the
  Matthew> person is really present - they are more 'positive' in that
  Matthew> respect.  However, even though accepting that the last
  Matthew> positive event is authoritative most of the time, it can be
  Matthew> broken fairly easily.  Say I'm moving back and forth
  Matthew> between two hosts and two clients, both of which
  Matthew> (correctly) list me as online.  I log out of one host,
  Matthew> setting my status to 'unavailable' as I do so. 

perhaps at this point your second client should adjust its idea of
your status?  since you are subscribed to your default group anyway,
you will see your own status notifications.  you just need to compare
the duration on the info, and update your internal idea of your state
accordingly?

clients would still need to display the newest value, cos the first
time the second client was used there'd be two different status
values, but after that, i think this might be better behaviour?

  Matthew> I also really want to have automatic 'unavailable?' as
  Matthew> standard in full-featured clients because we tend to forget
  Matthew> about setting our status.

i totally agree, but i was wondering about separating the concept of
availability and the, perhaps distinct, notion of the accuracy of
the status?

this could also allow the reverse of "unavailable?": if your status
says "unavailable" or "offline", but you've been sending ticker
messages (or some other activity), then your status could be marked as
possibly inaccurate, or effectively "available?"


  Matthew> I absolutely agree with keeping things simple, even at the
  Matthew> cost of losing some cool features. I'd say the spec is too
  Matthew> complex if an average hacker can't put together a halfway
  Matthew> useful presence implementation in an hour or two - I don't
  Matthew> think we've crossed that line yet.

i was just wondering if the status value was actually confusing two
things into a single value, and if separating them was better.

i don't think we need to lose any features.  and the automatic
downgrading of an online status if there's no activity is very
important.




d



From ilister at dstc.edu.au  Wed Nov  7 07:50:45 2001
From: ilister at dstc.edu.au (Ian Lister)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Elvin presence specification draft
In-Reply-To: <20011106155015.A6152@magnetic-ink.dk>
Message-ID: 


On Tue, 6 Nov 2001, Klaus Alexander Seistrup wrote:
>Martin Wanicki wrote:
>> Sooooo here's my suggestion.
>>
>> Status becomes a number.
>>     Negative One       (-1)     = off-line
>>     Zero	         ( 0 )    = Available
>>     Positive Non-Zero	 (1..???) = some "Unavailable" status event
>
>I'm sorry Martin, but I do not support your suggestion.

I agree with Klaus; encoding status as arbitrary numbers isn't (and
shouldn't be) the `Elvin way'. It would be a step towards a world where
packets are a fixed sequence of bytes rather than open and flexible
natural expressions of the status.

I like to try to think of making notifications more generally useful than
being tied to a single protocol.

This is also related to the `notification naming conventions' discussion
on elvin-dev following the Ticker workshop (archives at
http://elvin.dstc.edu.au/ListArchive/elvin-dev/archive/2001/09/); it's
something that's required to realise the full strength of Elvin's
decoupling, extensibility, etc.

Ian




From Martin.Wanicki at Australia.Boeing.com  Wed Nov  7 10:46:19 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: presence protocol 0.3.1 request for clarification
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A609D0B@xch-bne-01.bal.bna.boeing.com>


Firstly item 3.4 the sample exchange..

Been looking at this and attempting an implementation, and there seems no
reason to emit an announcement on startup.
Won't Emitting a presence request, get a response from the current client as
well as all the others?
It does in my trail client anyway, which means I emit two presence info's
instead of one.. 

I really would like some clarifaction of the semantics and use of the
wildcards, if anyone can clear that up I'd be most grateful.

Cheers


Martin








From Matthew.Phillips at dsto.defence.gov.au  Fri Nov  9 15:21:23 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single us er
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBB7@salex005.dsto.defence.gov.au>


This has been worrying me, because I couldn't find anything wrong with
David's points here, and yet I still felt there was a problem with this
approach. 

Essentially David's proposal is that clients accept the most recent status
as correct, and when you're running multiple clients they update their
internal status setting to the last info they saw go by with your name on
it.  Also, when no activity has been seen from someone for a while, all
other clients downgrade their certainty about their status (eg 'Online?').
Note that this scheme would require some sort of regular 'heartbeat' from
clients that actually know you are active (eg via keystroke monitoring) to
convince everyone else you're still there: not too pretty, but doable.

But then it dawned on me that we are forgetting that there is a lot more to
presence than status.  When I move clients my presence info may change in a
number of ways eg my 'x-Location' might change from 'Work' to 'Home' or I
might subscribe to different groups.  But in order for the most recent info
to deliver this information, clients would have to generate full info
notifications all the time, rather than the nicely efficient differential
approach currently specified.  I suppose clients _could_ set a flag when
their status is set by another client for the same person and generate a
full info next time the user changed status on that client, but I imagine
that by now we have added at least as much overhead as just maintaining more
than one presence info and displaying the 'most online' one.

My 200c worth,

Matthew.



From Martin.Wanicki at Australia.Boeing.com  Tue Nov 20 11:17:45 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: Further to the debate about possible expired(bogus) status  and some other stuff..
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A7A756C@xch-bne-01.bal.bna.boeing.com>


Dear All

If a client sends a request and receives no response from person(s client)
for which it is 
currently maintaining status information could it not then safely mark that
persons status information as offline.


In section 3.9 of the draft spec 0.3.1 makes mention of a status-info
attribute which doesn't exist in the formats.
If the 'presence-info' attribute is actually the one being discussed in that
section, the content of the attribute "reply"
is also in error, and indeed the example could not easily be reproduced
using the notification format as described in section 3.7 and the
subscription example in 3.9 
A client could, I suppose exclude all notifications that do not contain
"initial" or "update" as the contents of the presence attribute,
but ever the advocate for simplicity, I make the following comments..

In actual implementation of the protocol, I'm wondering about the practical
importance of the different Presence-Info
types. If you add "Status" "Status-Text" and "Duration" as the minimum
*required* set of information the info type really doesn't matter
Sure, identify it as either an unsolicited notification or a reply so that a
client can for whatever reason opt out of replies, 
but this seems sufficient to me.
Handle the missing attributes and only update the registry with the supplied
information seems a reasonable approach, (to me)

Also I'd like to open debate on the presence protocol being used for
initiation of a one-on-one conversation rather than the thread_id of the
tickertape format.
I'm not suggestion thread-id be canned from the other format, its *really*
useful for the "kill thread" option, but not so much for the one-on-one
stuff, I don't think.
I'm thinking that to integrate a conversation initiation into the presence
protocol might be a good thing. 
Or should we develop something more along the lines of the conversation
initiation that Julian discussed for secure messaging in the workshop?

Over to y'all

Cheers

Martin





From Matthew.Phillips at dsto.defence.gov.au  Wed Nov 21 10:17:51 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Further to the debate about possible expired(bogus) status  and s ome other stuff..
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBDA@salex005.dsto.defence.gov.au>


Hi all,

> If a client sends a request and receives no response from 
> person(s client)
> for which it is 
> currently maintaining status information could it not then 
> safely mark that
> persons status information as offline.

This is true.  The offline status is still needed though for when a client
is shutting down and wants to indicate it is no longer there.  If we don't
have this, we will have to rely on all clients sending fairly regular
'heartbeat' updates in order not to disappear off everyone else's screens.
One of the nice things about the current approach is that, once everyone is
clear about who's out there and what their info is, nothing needs to be
transmitted until someone's state changes.

> In section 3.9 of the draft spec 0.3.1 makes mention of a status-info
> attribute which doesn't exist in the formats.

This is a typo: 'Status-Info' should have been 'Presence-Info'.  This has
been corrected in the next revision.

> If the 'presence-info' attribute is actually the one being 
> discussed in that
> section, the content of the attribute "reply"
> is also in error, and indeed the example could not easily be 
> reproduced
> using the notification format as described in section 3.7 and the
> subscription example in 3.9 

This example was originally correct, but after accepting that "reply" could
be left out of this field I forgot to update the later example.

> A client could, I suppose exclude all notifications that do 
> not contain
> "initial" or "update" as the contents of the presence attribute,
> but ever the advocate for simplicity, I make the following comments..
> 
> In actual implementation of the protocol, I'm wondering about 
> the practical
> importance of the different Presence-Info
> types. If you add "Status" "Status-Text" and "Duration" as the minimum
> *required* set of information the info type really doesn't matter
> Sure, identify it as either an unsolicited notification or a 
> reply so that a
> client can for whatever reason opt out of replies, 
> but this seems sufficient to me.
> Handle the missing attributes and only update the registry 
> with the supplied
> information seems a reasonable approach, (to me)

I think it is important since it allows clients, if they wish, to optimize
what they see.  If they do not want to see replies to requests from others,
then they can specify that be the case, if they don't care that's fine too.
If we leave the option for this sort of capability out now, it will be very
hard to add later and it's not hard to implement.

> Also I'd like to open debate on the presence protocol being used for
> initiation of a one-on-one conversation rather than the 
> thread_id of the
> tickertape format.
> I'm not suggestion thread-id be canned from the other format, 
> its *really*
> useful for the "kill thread" option, but not so much for the 
> one-on-one
> stuff, I don't think.
> I'm thinking that to integrate a conversation initiation into 
> the presence
> protocol might be a good thing. 
> Or should we develop something more along the lines of the 
> conversation
> initiation that Julian discussed for secure messaging in the workshop?

My take on this that presence is for seeing who's out there in order to send
them a message, but once that's done, there's no reason to use a different
protocol to send the message or use a different interface to read the
message.  The 'personal messaging' approach enabled by auto thread
subscription has been working well here and seems intuitive to our local
users: they simply select a person from the 'online' window and double-click
to send a ticker message to them.

I'm sure presence could aid the initiation of secure conversations.  One way
might by publishing the person's public key, assuming that the presence info
itself can be authenticated.

Cheers,

Matthew.




From Matthew.Phillips at dsto.defence.gov.au  Fri Nov 23 10:07:48 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single us er
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBE4@salex005.dsto.defence.gov.au>


Hello all,

this list seems to have died of late.  I was wondering if anyone had any
comments on anything? ;)

In particular, I'd like to start implementing the standardized presence
support in Sticker and, at this point, I am planning to use a Client-ID
field to handle overloaded Presence-Info's.  I'll ensure it supports the
current crop of presence clients which don't do the ID field though.

Cheers,

Matthew.



From Martin.Wanicki at Australia.Boeing.com  Fri Nov 23 10:42:13 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Multiple presence clients for a single us er
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A8BF6B5@xch-bne-01.bal.bna.boeing.com>


I'm in favour of a Client-ID, but should there be some discussion as to its
use?

Like...

..	Should it be a unique ID generated each time a client starts al-la
Session-Id  ?

..	Should it be locked/tied to the machine upon which the client is
running ?
		and if so should it have a machine part and a client part 
		ie "Client-Id : Some_Unique_Id@Machine_Id" or something to
that effect?
		This sounds like it gives away too much privacy, but
presence is about giving 
		away information so it could be useful to be able determine
if one of the 
		clients for user "XYZ" on Machine "ABC" is currently in
"State" 

..	etc


These are just a few ideas, and I'm sure there's pro's and cons for them and
others.

I'm not advocating a particular scheme here, just offering up some
suggestions for debate.


Cheers


Martin


> ----------
> From: 	Phillips, Matthew[SMTP:Matthew.Phillips@dsto.defence.gov.au]
> Sent: 	Friday, November 23, 2001 10:01 AM
> To: 	ticker-dev (E-mail)
> Subject: 	RE: [ticker-dev] Multiple presence clients for a single us
> er 
> 
> Hello all,
> 
> this list seems to have died of late.  I was wondering if anyone had any
> comments on anything? ;)
> 
> In particular, I'd like to start implementing the standardized presence
> support in Sticker and, at this point, I am planning to use a Client-ID
> field to handle overloaded Presence-Info's.  I'll ensure it supports the
> current crop of presence clients which don't do the ID field though.
> 
> Cheers,
> 
> Matthew.
> 



From bill at dstc.edu.au  Fri Nov 23 17:40:18 2001
From: bill at dstc.edu.au (Bill Segall)
Date: Tue Oct 14 08:01:40 2003
Subject: [ Forw: "Sachin Kulkarni" ] Re: Tickertape features
Message-ID: <200111230740.fAN7eIO10544@piglet.dstc.edu.au>


Forwarded with permission - Sachim has now joined ticker-dev ...

------- Forwarded Message

Replied: Fri, 23 Nov 2001 16:24:23 +1000
Replied: ""Sachin Kulkarni"  , me"
Resent: Fri, 23 Nov 2001 15:48:13 +1000
Resent: "elvin-mgmt@dstc.com "
Return-Path: sachink@dstc.edu.au
Delivery-Date: Fri, 23 Nov 2001 15:43:09 +1000
Received: from ip-gw7-4.dirtbike.net (pop3.iicinternet.com [64.156.139.200])
	by piglet.dstc.edu.au (8.11.3/8.11.3) with SMTP id fAN5h4O29494
	for ; Fri, 23 Nov 2001 15:43:04 +1000 (EST)
Received: (qmail 8826 invoked by uid 508); 23 Nov 2001 05:46:02 -0000
Delivered-To: segall.net-bill@segall.net
Received: (qmail 8819 invoked by alias); 23 Nov 2001 05:46:01 -0000
Received: from unknown (HELO piglet.dstc.edu.au) (130.102.176.1)
  by pop3.iicinternet.com with SMTP; 23 Nov 2001 05:46:01 -0000
Received: from somepc210 (somepc210.dstc.edu.au [130.102.177.210])
	by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id fAN5grO29432;
	Fri, 23 Nov 2001 15:42:54 +1000 (EST)
From: "Sachin Kulkarni" 
To: 
Cc: 
Subject: Re: Tickertape features
Date: Fri, 23 Nov 2001 15:42:57 +1000
Message-ID: <001501c173e1$b4f426e0$d2b16682@somepc210>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0016_01C17435.86A036E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)

This is a multi-part message in MIME format.

- ------=_NextPart_000_0016_01C17435.86A036E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi
I have been using various IM clients for 3/4 yrs now. Every new feature
of those clients still fascinates me. I recently started using our own
Tickertape ( eTix client). I found following features either missing in
client or not supported by Tickertape. I must admit that I still haven't
fully explored the tool. Or maybe some features are just not relevant to
the base theory.
 
Retrieve available Channel list
Subscription retrieval; majordomo style 
Activity analysis of channels
Repository of responses (X asks questions, Y replies, Z starts
tickertape asks same question so on) 
Repository of service clients ( weather, stock quotes etc ) 
Personalisation (based on service clients; personalise info messages) 
Authorisation 
Web-interface 
Visualisation (IMvironment (yahoo term))
Email notification on tickertape 
Ads support (for commercialisation) 
Status based message control (no subscriber of 'Chat' channel is
currently online or available) 
Multiple identities
Invite /remove subscription (moderator role for channels)
Emoticons 
Record conversation
Spam proof? Ignore sender, message (ex. 'Word 'Beer' mentioned n
times..' )
Voice support 
Encrypted chat
WAP/Mobile Clients support 
 
Sorry for being overenthusiastic about expectation :-)
 
- -Sachin

- ------=_NextPart_000_0016_01C17435.86A036E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






















Hi



I have been using various IM clients for 3/4 =
yrs now. Every
new feature of those clients still fascinates me. I recently started =
using our
own Tickertape ( eTix client). I found =
following features
either missing in client or not supported by Tickertape. I must admit =
that I still
haven’t fully explored the tool. Or maybe some features are just =
not relevant
to the base theory.



 



Retrieve available Channel =
list



Subscription retrieval; majordomo style =




Activity analysis of =
channels



Repository of responses (X asks questions, Y =
replies,
Z starts tickertape asks same question so on) =




Repository of service clients (
weather, stock quotes etc ) 



Personalisation (based on service clients; =
personalise
info messages) 



Authorisation 



Web-interface 



Visualisation (IMvironment (yahoo =
term))



Email notification on tickertape =




Ads support (for commercialisation) =




Status based message control (no subscriber =
of ‘Chat’
channel is currently online or available) 



Multiple =
identities



Invite /remove subscription (moderator role =
for
channels)



Emoticons 



Record =
conversation



Spam proof? Ignore sender, message (ex. =
‘Word ‘Beer’
mentioned n times….’ =
)



Voice support 



Encrypted chat



WAP/Mobile Clients support =




 



Sorry for being overenthusiastic about =
expectation J



 



-Sachin









- ------=_NextPart_000_0016_01C17435.86A036E0--


------- End of Forwarded Message




From bill at dstc.edu.au  Fri Nov 23 17:41:35 2001
From: bill at dstc.edu.au (Bill Segall)
Date: Tue Oct 14 08:01:40 2003
Subject: [ Forw: "Bill Segall" ] Re: Tickertape features
Message-ID: <200111230741.fAN7fZO10704@piglet.dstc.edu.au>


------- Forwarded Message

To: "Sachin Kulkarni" 
Cc: martin@wanicki.com, bill@segall.net
Subject: Re: Tickertape features 
Reply-to: Bill Segall 
X-URL: 
X-Attribution: Bill
X-Face: /)"JC9!6kIJ)d](5gQ 
Date: Fri, 23 Nov 2001 16:24:22 +1000
From: "Bill Segall" 

Sachin,

Thanks for that list. Some things you might like to know ...

>Retrieve available Channel list

This is something that really doesn't exist within Elvin because of
concerns about global scalability. There is almost a way to do seomthing
with an elvin feature called quenching but there is no central respository
of channels.

There is a web page on the Elvin web that contains some information at:
http://elvin.dstc.edu.au/projects/producers/tickernews.html

>Subscription retrieval; majordomo style 

Again not really an Elvin feature although Julian has some ideas about
repositories for this sort of info.

>Activity analysis of channels

Nice idea.

>Repository of responses (X asks questions, Y replies, Z starts
>tickertape asks same question so on) 

Actually there is significant commercial interest in these from both Boeing
and SAP. I've always liked teh idea of an anser garden and the logging part
of this is mostly done. The scuttlebut folks are playing in this space.

>Repository of service clients ( weather, stock quotes etc ) 
see url above ...

>Personalisation (based on service clients; personalise info messages) 

would be nice.

>Authorisation 
>Encrypted chat

Elvin doesn't yet support authorisation although security is
possible. The aquatik (MacOS-X) and jinx (java) clients have the beginnings
of secure communication built on the Elvin security model but teh clients
have been slow to adopt this.

>Web-interface 

For posting see:
http://internal.dstc.edu.au/cgi-bin/ticker.py?user+10+elvin

There also applet tickers available:
http://elvin.dstc.edu.au/projects/sticker/sticklet.html
http://elvin.dstc.edu.au/projects/je4/applet/index.html

>Visualisation (IMvironment (yahoo term))

Could you elaborate?

>Email notification on tickertape 

This can be done quite easily:
http://elvin.dstc.edu.au/projects/tickertape/mail.html

>Ads support (for commercialisation) 

Noooooooo! :-) Oh ok, I think you just configure the installer's to have
the ad groups.

>Status based message control (no subscriber of 'Chat' channel is
>currently online or available) 

Some of the newer clients (sticker2, aquatik) support this.

>Multiple identities

You get to fake your id but I guess this not the same.

>Invite /remove subscription (moderator role for channels)
I like it ... etiks does allow a network install where only the
administrator can control the groups.

>Emoticons 

;-}

>Record conversation

See:
http://internal.dstc.monash.edu.au/ticker
http://virgil.dstc.edu.au/cgi-bin/tickerlog_cgi

>Spam proof? Ignore sender, message (ex. 'Word 'Beer' mentioned n
>times..' )

Some clients have advanced subscriptions that allow this sort of
thing. etiks can do this for you through the subscriptions file.

>Voice support 

I shared a room with Andy Bond in about 1996 and he had this hacked
together. I p[romised I'd never let it happen again :-)


See security above.

>WAP/Mobile Clients support 

The M3 guys had WAP phones sending/receiving tickertape events running last
year sometime. You could ask them about it and they may even still be able
to do a demo for you.

>Sorry for being overenthusiastic about expectation :-)

Not at all, this is all good stuff. ... want to help implement?

Also, there is a majordomo mailing list called ticker-dev that you might
like to join for which we discuss things like this ... with your permission
I'd forward your mail and my response to it.

Bill.

------- End of Forwarded Message




From bill at dstc.edu.au  Fri Nov 23 17:42:00 2001
From: bill at dstc.edu.au (Bill Segall)
Date: Tue Oct 14 08:01:40 2003
Subject: [ Forw: "Sachin Kulkarni" ] RE: Tickertape features
Message-ID: <200111230742.fAN7g0O10825@piglet.dstc.edu.au>


last of the series ... now everyone gets to play :-)
------- Forwarded Message

Return-Path: sachink@dstc.edu.au
Delivery-Date: Fri, 23 Nov 2001 17:25:39 +1000
Received: from ip-gw7-4.dirtbike.net (pop3.iicinternet.com [64.156.139.200])
	by piglet.dstc.edu.au (8.11.3/8.11.3) with SMTP id fAN7PbO09860
	for ; Fri, 23 Nov 2001 17:25:37 +1000 (EST)
Received: (qmail 25185 invoked by uid 508); 23 Nov 2001 07:28:35 -0000
Delivered-To: segall.net-bill@segall.net
Received: (qmail 25180 invoked by alias); 23 Nov 2001 07:28:35 -0000
Received: from unknown (HELO piglet.dstc.edu.au) (130.102.176.1)
  by pop3.iicinternet.com with SMTP; 23 Nov 2001 07:28:35 -0000
Received: from somepc210 (somepc210.dstc.edu.au [130.102.177.210])
	by piglet.dstc.edu.au (8.11.3/8.11.3) with ESMTP id fAN7PWO09849
	for ; Fri, 23 Nov 2001 17:25:32 +1000 (EST)
From: "Sachin Kulkarni" 
To: "'Bill Segall'" 
Subject: RE: Tickertape features 
Date: Fri, 23 Nov 2001 17:25:36 +1000
Message-ID: <002601c173f0$0bd29560$d2b16682@somepc210>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3311
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <200111230624.fAN6OLO05004@piglet.dstc.edu.au>
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)

>Visualisation (IMvironment (yahoo term))

Could you elaborate?
[Sachin] applying themes to message (scroll) window. (only yahoo
currently supports such themes; has dilbert strip as one of those themes
:)) 

>Multiple identities

You get to fake your id but I guess this not the same.

[Sachin] may not be useful for Tickertape. I have two msn identities, I
log- on onto remote server using terminal services (W2K). Start msn on
that server using identity I (you can't simultaneously use same ID), it
supports file transfer. so start file transfer from there and receive
file on home PC where I am using MSN as I'. Weird. Isn't it? But
sometimes more efficient that conventional ways. 
of course there are other creative ways of using this facility. For
instance Home users can have one client & different identities with
different subscriptions. Or my week-end profile will have entirely
different set of subscriptions than my week-day profile.  

>Emoticons 

;-}
[Sachin] with little more visual effects
[http://help.microsoft.com/EN_US/HelpWindow_msg.asp?INI=msgr_msnv45.ini&
H_VER=1.7&SearchTerm=nogol&S_Text=For%20help%20on%20MSN%20Messenger,%20c
lick%20a%20topic%3A&H_APP=MSN%20Messenger&Filter=msn ]

>Spam proof? Ignore sender, message (ex. 'Word 'Beer' mentioned n
>times..' )

Some clients have advanced subscriptions that allow this sort of
thing. etiks can do this for you through the subscriptions file.

[Sachin] can ignore specific user? Or messages filtering for security or
Adult contents  

>Sorry for being overenthusiastic about expectation :-)

Not at all, this is all good stuff. ... want to help implement?


[Sachin] well, yes with a little I know about. Currently working in Web
services area. But Charles already implemented Elvin notification web
service :-(
(http://uddi.microsoft.com/Details/ServiceDetail.aspx?serviceID=e39065a8
- -d9bd-4497-a5f8-e5fa7b9562f3)  
Nonetheless, we are planning to use that for BCA Notification systems.
So will be playing with that soon.

[Sachin] Of course, you can send this email with your answers to the
ticker-dev list. I have requested subscription for myself. 

Thanks a lot for quick answers. I'll go through suggested ref.



------- End of Forwarded Message




From Martin.Wanicki at Australia.Boeing.com  Mon Nov 26 10:01:07 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: Bots, Presence, Personal Channels, Transient Subscriptions and 'Thread-Id'
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A8BFBBE@xch-bne-01.bal.bna.boeing.com>


At TickerFest 2001, Matthew Phillips introduced the notion of personal
channels, which function
roughly as follows, (Mathew might wish to actually spec this out?)

A ticker client subscribes to a channel in the form of ( TICKERTAPE ==
'foo@bar' )
where 'foo@bar' is the current users name/domain* pair. 

To initiate a one on one chat with user 'foo@bar' another person would send
a message to that channel
Upon reciept of a notification to a personal channel the client 'foo@bar' is
using automatically subscribes to the 
thread-id** contained within the notification with a transient subscription,
thereby ensuring replies to the message are received locally
and also ensuring the subscription dies after some predefined period has
elapsed.	

*  The notion of the 'user@domain' pair , although used informally for some
time, has been introduced as
mandatory for ticker clients implementing the presence protocol
http://elvin.dstc.edu.au/ListArchive/ticker-dev/archive/2001/10/msg00029.htm
l
(also introduced at TickerFest 2001)

** The notion of a 'Thread-Id' has also been in informal use for sometime by
various clients and was also intorduced more formally at TickerFest 2001
    'Thread-Id' is a text attribute added to every notification a client
replies to.
    If 'Thread-Id' does not exist in the original (about-to-be-replied-to)
notification, the 'Message-Id' is copied into its place.
    This allows us to implement conversation thread blocking as well as
transient subscriptions 
   

Here's how all this might be useful for bots...

If we ratify these as standards, particularly the 'user@domain' format of
usernames and personal channels based on this name,
bots while listening to all channels can safely reply to only that channel,
therby removing unwanted bot traffic from other more populated
channels.
Further, if clients we set up to only emit bot queries on personal channels,
bots could subscribe to all queries with a simple
( contains( TICKERTAPE, '@' )  && contains( fold-case(TICKERTEXT)
,'my_bot_keyword/name','?' ) 

I understand that the use of a subscription " contains( TICKERTAPE, '@' ) "
opens up the possibilty of people watching 
other peoples conversations, but the additional use of keys would overcome
this privacy issue.


Over to y'all 

Cheers

Martin








From Martin.Wanicki at Australia.Boeing.com  Mon Nov 26 10:18:16 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: Avoiding/swatting duplicate notifications for client generated subscriptions
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A8BFBF7@xch-bne-01.bal.bna.boeing.com>


Duplicate notification swatting has always been something I've tried to
avoid like the plague, but the introduction
of client generated susbcriptions makes duplicate notifications entirely
more possible.

I am of the belief that all hand built subcriptions should function normally
and if a couple of these bring in duplicate notifications
it is the responsibility of the user to sort out their subscriptions.

However, clients implementing transient subscriptions and temporary
subscriptions created for the sole purpose of ensuring
the client gets its own notifications back, will possibly cause a client to
recieve the same notification against more than one subscription.

To overcome this and at the same time leave the user defined susbcriptions
to behave as normal, I have come up with a simple
approach that seems to work and offer it here for your comment.

The approach is based on the use and implementation ot the 'Replacement'
field in the Tickertape notification format spec.

ONLY on notifications received against client-generated or automatic
subscriptions do the following ...

Upon reciept of such a notification inspect the notification for the
existence of a 'Replacement' attribute, 
if it doesnt exist add the attribute and copy the contents of the
'Message-Id' field into it.
Then let your normal code do the the rest.

If your client has implemented the replacement attribute and functionality
you should never see more that one 
instance of the notificaion in your message threads or in the scroller.

Cheers

Martin





From Matthew.Phillips at dsto.defence.gov.au  Mon Nov 26 10:58:27 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Bots, Presence, Personal Channels, Transient Subscriptions and 'T hread-Id'
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EBF3@salex005.dsto.defence.gov.au>


> At TickerFest 2001, Matthew Phillips introduced the notion of personal
> channels, which function
> roughly as follows, (Mathew might wish to actually spec this out?)
> 
> A ticker client subscribes to a channel in the form of ( TICKERTAPE ==
> 'foo@bar' )
> where 'foo@bar' is the current users name/domain* pair. 
> 
> To initiate a one on one chat with user 'foo@bar' another 
> person would send
> a message to that channel
> Upon reciept of a notification to a personal channel the 
> client 'foo@bar' is
> using automatically subscribes to the 
> thread-id** contained within the notification with a 
> transient subscription,
> thereby ensuring replies to the message are received locally
> and also ensuring the subscription dies after some predefined 
> period has
> elapsed.	

Just a short clarification: user 'foo@bar' is 'permanently' subscribed to
foo@bar, the person sending the message to them becomes 'thread' subscribed.

I think using personal messaging for bot traffic is a neat idea.  Either
send a personal message to a specific bot eg "phone@bots.dsto" (which you
might spot via presence) or to your own personal group, to which the botd
reply.

Matthew.



From agerber at dstc.edu.au  Mon Nov 26 10:59:51 2001
From: agerber at dstc.edu.au (Anna Gerber)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Bots, Presence, Personal Channels, TransientSubscriptions and 'T hread-Id'
In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690A8BFBBE@xch-bne-01.bal.bna.boeing.com>
Message-ID: 



> If we ratify these as standards, particularly the 'user@domain' format of
> usernames and personal channels based on this name,
> bots while listening to all channels can safely reply to only that channel,
> therby removing unwanted bot traffic from other more populated
> channels.
> Further, if clients we set up to only emit bot queries on personal channels,
> bots could subscribe to all queries with a simple
> ( contains( TICKERTAPE, '@' )  && contains( fold-case(TICKERTEXT)
> ,'my_bot_keyword/name','?' )

I don't understand why the above is necessary or desirable. Currently,
most bots reply on the channel where they were asked, so if you don't
want to clutter up public channels, you invoke the bot on a personal
channel, however if you want to share the bot's response, you can invoke
it on a shared channel.  This model of interaction with bots is easy to
understand and seems to work well.

I don't like the idea of forcing bots to only listen/respond to channels
of the form 'user@domain' because it no longer allows the sharing of bot
responses on shared channels that don't have a name of this form.  (Aside
from issues I already have with standardising user@domain as a personal
channel name because I like to use the same personal channels regardless
of whether I am currently agerber@dstc or anna@home and also because I
like to have a number of different personal channels for different
purposes)

If your concern is with reducing bot clutter on public channels, then I
would prefer a key based solution (where users establish keys to be used
with each bot, so that they only see their own requests/responses)
because this is scalable to groups of people (who all use the same shared
key) and works for arbitrary channel names.

Anna




From Martin.Wanicki at Australia.Boeing.com  Mon Nov 26 11:51:11 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:40 2003
Subject: [ticker-dev] Bots, Presence, Personal Channels, Transient Subscriptions and 'T hread-Id'
Message-ID: <21BEC9503B89D111A8F700805FE6A3690A8BFD2D@xch-bne-01.bal.bna.boeing.com>



Firslty I dont want to "force" bots to bhave in this way, but I think it
would be nice if bots
afforded the user the option of keeping a query and its reply personal, and
sure, I understand
that bots tend to respond on the channel on which they are invoked, so thats
fine, however..

there may be cases where one would NOT want a prarticular bot ever respond
on a public channel, and the adoption of 
a standard way to behave for such bots might be a good idea.

Within this organisation I have already been asked to make bot traffic
invisible to public channels, this is partially 
because we have users here relatively new to the whole tickertape concept
who are still saying that lots of messages they arent interested in, is too
distracting.
and secondly this is a privacy and security concious establishment and these
issues are more the rule than the exception.

Also it seems that the sharing of a bots response encroaches on an
ettiquette issue.
For instance I dont see that I actually have the *right* to shove stuff on a
multitude of screens just cause I wanna share a bot response with one or a
few people.

It affords me some level of comfort to *know* that a bot wont respond on a
public channel, even if I accidentally post a bot query to a public channel.

Regarding the security issue, sure use keys, if they are available in the
API you're currently using :-)
The addition of security to the COM api will go sifficiently towards solving
the problems, but key distribution still represents a problem.

I do understand the desire for "open-ness" in the protocol, but the
corporate world is still firmly tied to the apron strings of yesteryear :-)
and as such 
tend to consider such open-ness to be something that can be explioted or
abused by personnel for any number of reasons, be they innocent, personal or
malicious.
*some* companies consider 'personal use' to be 'abuse'  and tend to frown on
anything that is too open to personal use :-(

Cheers

Martin
> ----------
> From: 	Anna Gerber[SMTP:agerber@dstc.edu.au]
> Sent: 	Monday, November 26, 2001 10:59 AM
> To: 	Wanicki, Martin
> Cc: 	ticker-dev@dstc.edu.au
> Subject: 	Re: [ticker-dev] Bots, Presence, Personal Channels,
> Transient Subscriptions and 'T hread-Id'
> 
> 
> > If we ratify these as standards, particularly the 'user@domain' format
> of
> > usernames and personal channels based on this name,
> > bots while listening to all channels can safely reply to only that
> channel,
> > therby removing unwanted bot traffic from other more populated
> > channels.
> > Further, if clients we set up to only emit bot queries on personal
> channels,
> > bots could subscribe to all queries with a simple
> > ( contains( TICKERTAPE, '@' )  && contains( fold-case(TICKERTEXT)
> > ,'my_bot_keyword/name','?' )
> 
> I don't understand why the above is necessary or desirable. Currently,
> most bots reply on the channel where they were asked, so if you don't
> want to clutter up public channels, you invoke the bot on a personal
> channel, however if you want to share the bot's response, you can invoke
> it on a shared channel.  This model of interaction with bots is easy to
> understand and seems to work well.
> 
> I don't like the idea of forcing bots to only listen/respond to channels
> of the form 'user@domain' because it no longer allows the sharing of bot
> responses on shared channels that don't have a name of this form.  (Aside
> from issues I already have with standardising user@domain as a personal
> channel name because I like to use the same personal channels regardless
> of whether I am currently agerber@dstc or anna@home and also because I
> like to have a number of different personal channels for different
> purposes)
> 
> If your concern is with reducing bot clutter on public channels, then I
> would prefer a key based solution (where users establish keys to be used
> with each bot, so that they only see their own requests/responses)
> because this is scalable to groups of people (who all use the same shared
> key) and works for arbitrary channel names.
> 
> Anna
> 



From david at mincom.com  Thu Dec  6 10:18:29 2001
From: david at mincom.com (David Cox)
Date: Tue Oct 14 08:01:40 2003
Subject: sticker 2.0.0 question, feedback
Message-ID: <3C0EB8F7.8020306@mincom.com>

Hi Matthew,

I've played with sticker for the last couple of weeks on:

PC, Windows 2000 SP1 with Java 1.3.0_01 (ok, I should upgrade)
Sun Ultra1-170E, Solaris 2.6 with Java 1.3.1-rc2 (as above)
SGI 2* Origin200/2*225 craylink'ed, Irix 6.5.5f with JavaVM 1.3
   (ok, SGI has a funny naming scheme for 1.3 original)
The Irix system is a main server and sticker was cpu-hungry. I'll put this down 
to SGI, since it's much better behaved on the other two (PC, )

Generally /very/ nice. Love the nifty message drag feature :)

I have a couple of questions and some other feedback. Do you want bugzilla logs 
for any/all of these?

1. How do you configure for server discovery?

Since couldn't work this out (ok, I gave up pretty easily), I configured for 
protocol:elvin server:elvin port:2917 (elvin is an alias for the server).
I'd have thought that leaving the server blank would do the trick, but c'est la vie.

2. Problems dropping and changing the elvind server.

I started elvind (4.1b1) on another system, then stopped the current main server 
  (4.0.2). Both were configured as 'default' servers (I know this is not nice), 
but for my current purposes it seems to work in most cases. eTiks and 
xtickertape successfully using server discovery.

sticker reported (correctly) that the server had vanished.

I edited the elvin config to change the server name, and got the following 
messages - see the attached log.

3. I use CDE with 4 'desktops' (whatever the term is) on Solaris. Is there some 
way to use the CDE decorations around the chat panel so that I can map it to all 
desktops? Maybe this is because I'm not using the 'real' install/execure script?

4. A 'nicety' option. When recalling 'show messages', can you optionally default 
to display the last group shown, instead of simply providing the list with 
'Chat' preselected?

5. When configuring new ticker rules, it took me a while to realise I needed to 
enter the  to make the name 'stick'. I was simply replacing 'Rule 4' with 
'Mincom' (no cr), then clicking close and was wondering why it did not 'take'. 
It seems if I click on anything else first it's fine ... I need to do some more 
experimenting with this though. I can't reproduce the original problem now, but 
seem to have some weird stuff (null pointer exception) going on if the name 
change without  is the /last/ thing I do before close ...
'Exception occurred during event dispatching', followed by 'hung' option panel. 
I 'x'ed the panel (this is on w2k). Seems to have recovered after that.
See attached log2.


Cheers, djc
-- 
David Cox   Research Liaison Manager,  Mincom Limited
Internet:   david@mincom.com   ph +61 7 3303-3131  fax +61 7 3303-3257
Smail:      GPO Box 1397, Brisbane, Qld 4001 *Australia*
World:      193 Turbot St, Brisbane, Qld 4000 *Australia*

This transmission is for the intended addressee only and is confidential 
information. If you have received this transmission in error, please delete it 
and notify the sender. The contents of this E-mail are the opinion of the writer 
only and are not endorsed by Mincom Limited unless expressly stated otherwise.


>>> Annotated sticker 2.0.0 log of events
>>> Shut down the elvin 4.0.2 server 'elvin' (solaris 2.5.1).
>>> The 4.1b1 server 'typhoon' (Irix 6.5.5f) is already running.

15:27:01 [Alarm] Lost Elvin connection: the server has closed the connection without warning
15:27:08 [Warning] Elvin reconnect failed: failed to reconnect - retrying in 120 seconds
15:27:09 [Warning] Failed to update Elvin Online: operation not available while disconnected
Exception trace:
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.doSendNotify(ConnectionRequests.java:335)
        at org.elvin.je4.ConnectionRequests.sendNotify(ConnectionRequests.java:113)
        at org.elvin.je4.Connection.sendNotification(Connection.java:950)
        at org.elvin.je4.Notification.emit(Notification.java:556)
        at org.elvin.je4.Producer.notify(Producer.java:134)
        at dsto.elvin.eonline.OnlineUserElvinProxy.notifyStatus(OnlineUserElvinProxy.java:159)
        at dsto.elvin.eonline.OnlineUserElvinProxy.userStatusChanged(OnlineUserElvinProxy.java:198)
        at dsto.elvin.eonline.AbstractUserProxy.propertyChange(AbstractUserProxy.java:90)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.eonline.ElvinOnlineUser.setStatus(ElvinOnlineUser.java:195)
        at dsto.elvin.sticker.Sticker.pushUserStatus(Sticker.java:498)
        at dsto.elvin.sticker.Sticker.reconnectFail(Sticker.java:765)
        at org.elvin.je4.ConnectionEventQueue.fireConnectionEvent(ConnectionEventQueue.java:140)
        at org.elvin.je4.ConnectionEventQueue.access$0(ConnectionEventQueue.java:106)
        at org.elvin.je4.ConnectionEventQueue$ConnEventWork.run(ConnectionEventQueue.java:184)
        at org.elvin.util.Worker.doWork(Worker.java:182)
        at org.elvin.util.Worker.run(Worker.java:110)

>>> Edit options >> elvin, change server to 'typhoon', and close

15:28:15 [Info] Connecting to server ElvinServer [elvin, typhoon, 2917]
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.doSendNotify(ConnectionRequests.java:335)
        at org.elvin.je4.ConnectionRequests.sendNotify(ConnectionRequests.java:113)
        at org.elvin.je4.Connection.sendNotification(Connection.java:950)
        at org.elvin.je4.Notification.emit(Notification.java:556)
        at org.elvin.je4.Producer.notify(Producer.java:134)
        at dsto.elvin.eonline.OnlineUserElvinProxy.notifyStatus(OnlineUserElvinProxy.java:159)
        at dsto.elvin.eonline.OnlineUserElvinProxy.dispose(OnlineUserElvinProxy.java:64)
        at dsto.elvin.eonline.ElvinOnlineManager.disconnect(ElvinOnlineManager.java:155)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:311)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.marshalRequest(ConnectionRequests.java:377)
        at org.elvin.je4.ConnectionRequests.doSendRequestReply(ConnectionRequests.java:309)
        at org.elvin.je4.ConnectionRequests.sendRequestWaitReply(ConnectionRequests.java:85)
        at org.elvin.je4.Connection.sendUnsubscribe(Connection.java:687)
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:450)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.eonline.ElvinUserRegistryProxy.unsubscribe(ElvinUserRegistryProxy.java:108)
        at dsto.elvin.eonline.ElvinUserRegistryProxy.dispose(ElvinUserRegistryProxy.java:72)
        at dsto.elvin.eonline.ElvinOnlineManager.disconnect(ElvinOnlineManager.java:156)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:311)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
15:28:16 [Alarm] Exception while writing property 'elvinServer': tried to remove an active subscription from the wrong conne
ction
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.subscribeGroups(TickerClient.java:258)
        at dsto.elvin.sticker.messages.TickerClient.subscribe(TickerClient.java:178)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:138)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:350)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.Error: error while writing property 'elvinServer': java.lang.reflect.InvocationTargetException
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:259)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
15:28:34 [Diagnostic] Persistent object "pub-chat.messages" is being unloaded
15:28:34 [Diagnostic] Persistent object "Chat.messages" is being unloaded
15:28:34 [Diagnostic] Persistent object "david@mincom.messages" is being unloaded

>>> Not sure what I did here, probably pulled down the status bar to review. Found to be 'offline'
15:29:05 [Diagnostic] Save persistent object "sticker2.xbml"
15:29:06 [Info] Connecting to server ElvinServer [elvin, thunder, 2917]
15:29:06 [Alarm] Exception while writing property 'elvinServer': tried to remove an active subscription from the wrong conne
ction
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.unsubscribe(TickerClient.java:151)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:120)
        at dsto.elvin.sticker.messages.TickerClient.disconnect(TickerClient.java:67)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:312)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.Error: error while writing property 'elvinServer': java.lang.reflect.InvocationTargetException
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:259)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Error in dispatch: Thread[OpennerWorker,6,main]: java.lang.NullPointerException
java.lang.NullPointerException
        at org.elvin.util.Worker.addWork(Worker.java:122)
        at org.elvin.je4.ConnectionEventQueue.postEvent(ConnectionEventQueue.java:97)
        at org.elvin.je4.ConnectionMaintainer.reopen(ConnectionMaintainer.java:328)
        at org.elvin.je4.ConnectionMaintainer.access$0(ConnectionMaintainer.java:293)
        at org.elvin.je4.ConnectionMaintainer$Openner.run(ConnectionMaintainer.java:448)
        at org.elvin.util.Worker.doWork(Worker.java:182)
        at org.elvin.util.Worker.run(Worker.java:110)
15:29:41 [Info] Connecting to server ElvinServer [elvin, typhoon, 2917]
15:29:41 [Alarm] Exception while writing property 'elvinServer': tried to remove an active subscription from the wrong conne
ction
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.unsubscribe(TickerClient.java:151)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:120)
        at dsto.elvin.sticker.messages.TickerClient.disconnect(TickerClient.java:67)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:312)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.Error: error while writing property 'elvinServer': java.lang.reflect.InvocationTargetException
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:259)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
15:32:25 [Diagnostic] Save persistent object "sticker2.xbml"
15:32:55 [Alarm] Error while disconnecting from Elvin: tried to remove an active subscription from the wrong connection
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.unsubscribe(TickerClient.java:151)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:120)
        at dsto.elvin.sticker.messages.TickerClient.disconnect(TickerClient.java:67)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:312)
        at dsto.elvin.sticker.Sticker.shutdown(Sticker.java:279)
        at dsto.elvin.sticker.Sticker$CmdExit.execute(Sticker.java:943)
        at dsto.dfc.commands.CommandToolBarSynchronizer.actionPerformed(CommandToolBarSynchronizer.java:581)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
15:32:55 [Diagnostic] Save persistent object "sticker2.xbml"
15:32:55 [Info] Sticker exiting (code 1)

>>> OK, time to give up. Exit nicely (from 'Exit' button) and restart
>>> ALright, I'm not using your proper control file also.

C:\>L:\"my programs"\sticker

C:\>set p=t:\java

C:\>java -jar t:\java\sticker.jar
15:33:09 [Info] Starting Sticker 2.0.0 (20-Nov-2001)...
15:33:10 [Diagnostic] Windows extensions failed to load
15:33:19 [Diagnostic] Load persistent object "sticker2.xbml"
15:33:33 [Info] Connected to Elvin

>>> This time we did connect properly to 'typhoon'.

16:03:58 [Diagnostic] Going into idle mode
16:06:51 [Diagnostic] Waking up from idle

>>> Now we've built, installed and started 4.1b1 on 'elvin' (solaris 2.5.1)
>>> Kill the 'typhoon' server (Irix 6.5.5f)

16:06:55 [Alarm] Lost Elvin connection: the server has closed the connection without warning
16:06:56 [Warning] Elvin reconnect failed: failed to reconnect - retrying in 120 seconds
16:06:56 [Warning] Failed to update Elvin Online: operation not available while disconnected
Exception trace:
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.doSendNotify(ConnectionRequests.java:335)
        at org.elvin.je4.ConnectionRequests.sendNotify(ConnectionRequests.java:113)
        at org.elvin.je4.Connection.sendNotification(Connection.java:950)
        at org.elvin.je4.Notification.emit(Notification.java:556)
        at org.elvin.je4.Producer.notify(Producer.java:134)
        at dsto.elvin.eonline.OnlineUserElvinProxy.notifyStatus(OnlineUserElvinProxy.java:159)
        at dsto.elvin.eonline.OnlineUserElvinProxy.userStatusChanged(OnlineUserElvinProxy.java:198)
        at dsto.elvin.eonline.AbstractUserProxy.propertyChange(AbstractUserProxy.java:90)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.eonline.ElvinOnlineUser.setStatus(ElvinOnlineUser.java:195)
        at dsto.elvin.sticker.Sticker.pushUserStatus(Sticker.java:498)
        at dsto.elvin.sticker.Sticker.reconnectFail(Sticker.java:765)
        at org.elvin.je4.ConnectionEventQueue.fireConnectionEvent(ConnectionEventQueue.java:140)
        at org.elvin.je4.ConnectionEventQueue.access$0(ConnectionEventQueue.java:106)
        at org.elvin.je4.ConnectionEventQueue$ConnEventWork.run(ConnectionEventQueue.java:184)
        at org.elvin.util.Worker.doWork(Worker.java:182)
        at org.elvin.util.Worker.run(Worker.java:110)

>>> Again, set the server to 'elvin'

16:07:43 [Info] Connecting to server ElvinServer [elvin, elvin, 2917]
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.doSendNotify(ConnectionRequests.java:335)
        at org.elvin.je4.ConnectionRequests.sendNotify(ConnectionRequests.java:113)
        at org.elvin.je4.Connection.sendNotification(Connection.java:950)
        at org.elvin.je4.Notification.emit(Notification.java:556)
        at org.elvin.je4.Producer.notify(Producer.java:134)
        at dsto.elvin.eonline.OnlineUserElvinProxy.notifyStatus(OnlineUserElvinProxy.java:159)
        at dsto.elvin.eonline.OnlineUserElvinProxy.dispose(OnlineUserElvinProxy.java:64)
        at dsto.elvin.eonline.ElvinOnlineManager.disconnect(ElvinOnlineManager.java:155)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:311)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
org.elvin.je4.NotConnectedException: operation not available while disconnected
        at org.elvin.je4.Connection.getProtocolStack(Connection.java:646)
        at org.elvin.je4.ConnectionRequests.marshalRequest(ConnectionRequests.java:377)
        at org.elvin.je4.ConnectionRequests.doSendRequestReply(ConnectionRequests.java:309)
        at org.elvin.je4.ConnectionRequests.sendRequestWaitReply(ConnectionRequests.java:85)
        at org.elvin.je4.Connection.sendUnsubscribe(Connection.java:687)
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:450)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.eonline.ElvinUserRegistryProxy.unsubscribe(ElvinUserRegistryProxy.java:108)
        at dsto.elvin.eonline.ElvinUserRegistryProxy.dispose(ElvinUserRegistryProxy.java:72)
        at dsto.elvin.eonline.ElvinOnlineManager.disconnect(ElvinOnlineManager.java:156)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:311)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:326)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
16:07:43 [Alarm] Exception while writing property 'elvinServer': tried to remove an active subscription from the wrong connection
16:07:43 [Info] Connected to Elvin
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.subscribeGroups(TickerClient.java:258)
        at dsto.elvin.sticker.messages.TickerClient.subscribe(TickerClient.java:178)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:138)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:350)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.Error: error while writing property 'elvinServer': java.lang.reflect.InvocationTargetException
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:259)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.editCommitRequested(BasicForm.java:370)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitRequested(BasicFormEditorEventSource.java:98)
        at dsto.dfc.forms.JTextFieldFormEditor.actionPerformed(JTextFieldFormEditor.java:141)
        at javax.swing.JTextField.fireActionPerformed(Unknown Source)
        at javax.swing.JTextField.postActionEvent(Unknown Source)
        at javax.swing.JTextField$NotifyAction.actionPerformed(Unknown Source)
        at javax.swing.SwingUtilities.notifyAction(Unknown Source)
        at javax.swing.JComponent.processKeyBinding(Unknown Source)
        at javax.swing.JComponent.processKeyBindings(Unknown Source)
        at javax.swing.JComponent.processKeyEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processKeyEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
16:08:11 [Diagnostic] Save persistent object "sticker2.xbml"
Error in dispatch: Thread[OpennerWorker,6,main]: java.lang.NullPointerException
java.lang.NullPointerException
        at org.elvin.util.Worker.addWork(Worker.java:122)
        at org.elvin.je4.ConnectionEventQueue.postEvent(ConnectionEventQueue.java:97)
        at org.elvin.je4.ConnectionMaintainer.reopen(ConnectionMaintainer.java:328)
        at org.elvin.je4.ConnectionMaintainer.access$0(ConnectionMaintainer.java:293)
        at org.elvin.je4.ConnectionMaintainer$Openner.run(ConnectionMaintainer.java:448)
        at org.elvin.util.Worker.doWork(Worker.java:182)
        at org.elvin.util.Worker.run(Worker.java:110)

>>> Leave it a while and see if it comes on line. Nope, too bad.

16:34:48 [Diagnostic] Save persistent object "sticker2.xbml"
16:34:49 [Diagnostic] Load persistent object "david@mincom.messages"
16:34:53 [Diagnostic] Load persistent object "elvin-boeing.messages"
16:35:15 [Alarm] Error while disconnecting from Elvin: tried to remove an active subscription from the wrong connection
Exception trace:
java.lang.IllegalStateException: tried to remove an active subscription from the wrong connection
        at org.elvin.je4.Subscription.unsubscribe(Subscription.java:447)
        at org.elvin.je4.Consumer.removeSubscription(Consumer.java:157)
        at dsto.elvin.sticker.messages.TickerClient.unsubscribe(TickerClient.java:151)
        at dsto.elvin.sticker.messages.TickerClient.setElvin(TickerClient.java:120)
        at dsto.elvin.sticker.messages.TickerClient.disconnect(TickerClient.java:67)
        at dsto.elvin.sticker.Sticker.disconnect(Sticker.java:312)
        at dsto.elvin.sticker.Sticker.shutdown(Sticker.java:279)
        at dsto.elvin.sticker.Sticker$CmdExit.execute(Sticker.java:943)
        at dsto.dfc.commands.CommandToolBarSynchronizer.actionPerformed(CommandToolBarSynchronizer.java:581)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
16:35:15 [Diagnostic] Save persistent object "sticker2.xbml"
16:35:15 [Info] Sticker exiting (code 1)

>>> So again we stop and restart sticker.

C:\>L:\"my programs"\sticker

C:\>set p=t:\java

C:\>java -jar t:\java\sticker.jar
16:35:29 [Info] Starting Sticker 2.0.0 (20-Nov-2001)...
16:35:30 [Diagnostic] Windows extensions failed to load
16:35:38 [Diagnostic] Load persistent object "sticker2.xbml"
16:35:57 [Info] Connected to Elvin

>>> And we connect w/o any problems.

16:50:40 [Diagnostic] Load persistent object "aus.tv.buffy.news"
16:51:01 [Diagnostic] Save persistent object "aus.tv.buffy.news"
17:01:13 [Diagnostic] Going into idle mode
17:01:39 [Diagnostic] Waking up from idle
17:10:21 [Diagnostic] Save persistent object "elvin-sse.messages"
17:10:24 [Diagnostic] Load persistent object "david@mincom.messages"
17:10:24 [Diagnostic] Persistent object "aus.tv.buffy.news" is being unloaded
17:10:38 [Diagnostic] Load persistent object "elvin-boeing.messages"
17:11:24 [Diagnostic] Save persistent object "elvin-boeing.messages"
17:23:19 [Diagnostic] Persistent object "Chat.messages" is being unloaded
17:23:19 [Diagnostic] Persistent object "david@mincom.messages" is being unloaded
17:23:19 [Diagnostic] Persistent object "elvin-boeing.messages" is being unloaded

>>> Just an experiment to see if it is possible to configure for server discovery

17:29:33 [Info] Connecting to server ElvinServer [, , 2917]
17:29:34 [Alarm] Failed to connect to Elvin: the elvin server at elvin://:2917 is not available: java.net.ConnectException:
Connection refused: no further information
Exception trace:
org.elvin.je4.ConnectFailedException: the elvin server at elvin://:2917 is not available: java.net.ConnectException: Connect
ion refused: no further information
        at org.elvin.je4.ConnectionMaintainer.syncOpen(ConnectionMaintainer.java:163)
        at org.elvin.je4.Connection.open(Connection.java:1020)
        at org.elvin.je4.Connection.init(Connection.java:1005)
        at org.elvin.je4.Connection.(Connection.java:141)
        at dsto.elvin.sticker.Sticker.connect(Sticker.java:346)
        at dsto.elvin.sticker.Sticker.propertyChange(Sticker.java:707)
        at dsto.dfc.util.BasicPropertyChangeSource.doFirePropertyChange(BasicPropertyChangeSource.java:181)
        at dsto.dfc.util.BasicPropertyChangeSource.firePropertyChange(BasicPropertyChangeSource.java:101)
        at dsto.elvin.sticker.StickerProperties.setElvinServer(StickerProperties.java:165)
        at java.lang.reflect.Method.invoke(Native Method)
        at dsto.dfc.util.BeanUtility.setPropertyValue(BeanUtility.java:203)
        at dsto.dfc.forms.BasicForm.unloadEditor(BasicForm.java:234)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:388)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditComitted(BasicFormEditorEventSource.java:63)
        at dsto.dfc.forms.BasicForm.editCommitted(BasicForm.java:394)
        at dsto.dfc.forms.BasicFormEditorEventSource.fireEditCommitted(BasicFormEditorEventSource.java:80)
        at dsto.dfc.forms.JTextFieldFormEditor.commitEdits(JTextFieldFormEditor.java:106)
        at dsto.dfc.forms.BasicForm.commitChildren(BasicForm.java:274)
        at dsto.dfc.forms.BasicForm.commitEdits(BasicForm.java:289)
        at dsto.dfc.forms.BasicForm.commitChildren(BasicForm.java:274)
        at dsto.dfc.forms.BasicForm.commitEdits(BasicForm.java:289)
        at dsto.dfc.forms.FormPanel.commitEdits(FormPanel.java:105)
        at dsto.dfc.forms.CustomizersPanel.commitEdits(CustomizersPanel.java:148)
        at dsto.elvin.sticker.customizers.StickerOptionsDialog.cancel(StickerOptionsDialog.java:59)
        at dsto.dfc.ui.DfcDialog.cancelButton_actionPerformed(DfcDialog.java:206)
        at dsto.dfc.ui.DfcDialog$2.actionPerformed(DfcDialog.java:229)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
17:29:35 [Info] Entering offline elvin loopback mode
17:29:39 [Diagnostic] Save persistent object "sticker2.xbml"
17:30:09 [Diagnostic] Save persistent object "sticker2.xbml"
17:30:29 [Diagnostic] Save persistent object "sticker2.xbml"

>>> I tried other options on Solaris: all blank, servre as '*', protocol and server blank etc.
>>> All to no avail
>>> "You are in a maze of twisty little options, all the same"
>>> "You are at Witt's End"
>>> Apologies to Adventure (I think this is right maze - it's been a long time)

17:30:31 [Info] Connecting to server ElvinServer [elvin, elvin, 2917]
17:30:32 [Info] Connected to Elvin
17:30:50 [Diagnostic] Save persistent object "sticker2.xbml"

Exception occurred during event dispatching:
java.lang.NullPointerException
        at dsto.elvin.sticker.filters.RuleListTableModel.getRowCount(RuleListTableModel.java:162)
        at javax.swing.JTable.getRowCount(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.repaintAnchorCell(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.focusLost(Unknown Source)
        at java.awt.AWTEventMulticaster.focusLost(Unknown Source)
        at java.awt.Component.processFocusEvent(Unknown Source)
        at javax.swing.JComponent.processFocusEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.Component.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at javax.swing.JTable.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeNotify(Unknown Source)
        at javax.swing.JComponent.removeNotify(Unknown Source)
        at java.awt.Container.removeAll(Unknown Source)
        at dsto.dfc.ui.DfcDialog.dispose(DfcDialog.java:72)
        at dsto.dfc.ui.DfcDialog.setVisible(DfcDialog.java:174)
        at dsto.dfc.ui.DfcDialog.cancel(DfcDialog.java:141)
        at dsto.elvin.sticker.customizers.StickerOptionsDialog.cancel(StickerOptionsDialog.java:62)
        at dsto.dfc.ui.DfcDialog.cancelButton_actionPerformed(DfcDialog.java:206)
        at dsto.dfc.ui.DfcDialog$2.actionPerformed(DfcDialog.java:229)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.NullPointerException
        at dsto.elvin.sticker.filters.RuleListTableModel.getRowCount(RuleListTableModel.java:162)
        at javax.swing.JTable.getRowCount(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.repaintAnchorCell(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.focusLost(Unknown Source)
        at java.awt.AWTEventMulticaster.focusLost(Unknown Source)
        at java.awt.Component.processFocusEvent(Unknown Source)
        at javax.swing.JComponent.processFocusEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processFocusEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.NullPointerException
        at dsto.elvin.sticker.filters.RuleListTableModel.getRowCount(RuleListTableModel.java:162)
        at javax.swing.JTable.getRowCount(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.repaintAnchorCell(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.focusGained(Unknown Source)
        at java.awt.AWTEventMulticaster.focusGained(Unknown Source)
        at java.awt.Component.processFocusEvent(Unknown Source)
        at javax.swing.JComponent.processFocusEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processFocusEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
09:52:59 [Diagnostic] Save persistent object "sticker2.xbml"
Exception occurred during event dispatching:
java.lang.NullPointerException
        at dsto.elvin.sticker.filters.RuleListTableModel.getRowCount(RuleListTableModel.java:162)
        at javax.swing.JTable.getRowCount(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.repaintAnchorCell(Unknown Source)
        at javax.swing.plaf.basic.BasicTableUI$FocusHandler.focusLost(Unknown Source)
        at java.awt.AWTEventMulticaster.focusLost(Unknown Source)
        at java.awt.Component.processFocusEvent(Unknown Source)
        at javax.swing.JComponent.processFocusEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.setFocusRequest(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Container.proxyRequestFocus(Unknown Source)
        at java.awt.Component.requestFocus(Unknown Source)
        at javax.swing.JComponent.grabFocus(Unknown Source)
        at javax.swing.JComponent.requestFocus(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mousePressed(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
Exception occurred during event dispatching:
java.lang.IllegalStateException: Can't dispose InputContext while it's active
        at sun.awt.im.InputContext.dispose(Unknown Source)
        at java.awt.Window$1$DisposeAction.run(Unknown Source)
        at java.awt.Window.dispose(Unknown Source)
        at java.awt.Dialog.disposeImpl(Unknown Source)
        at java.awt.Dialog.dispose(Unknown Source)
        at dsto.dfc.ui.DfcDialog.dispose(DfcDialog.java:74)
        at dsto.dfc.ui.DfcDialog.setVisible(DfcDialog.java:174)
        at dsto.dfc.ui.DfcDialog.cancel(DfcDialog.java:141)
        at dsto.elvin.sticker.customizers.StickerOptionsDialog.cancel(StickerOptionsDialog.java:62)
        at dsto.dfc.ui.DfcDialog.cancelButton_actionPerformed(DfcDialog.java:206)
        at dsto.dfc.ui.DfcDialog$2.actionPerformed(DfcDialog.java:229)
        at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.awt.Component.processMouseEvent(Unknown Source)
        at java.awt.Component.processEvent(Unknown Source)
        at java.awt.Container.processEvent(Unknown Source)
        at java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.awt.Component.dispatchEvent(Unknown Source)
        at java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpOneEvent(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.run(Unknown Source)
09:53:19 [Diagnostic] Save persistent object "sticker2.xbml"


From Matthew.Phillips at dsto.defence.gov.au  Tue Dec 11 13:18:59 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:41 2003
Subject: Presence specification draft 0.4
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EC29@salex005.dsto.defence.gov.au>

Hi all,

due to lack of any opposition and finally getting some free time for fun
stuff, I've updated the Elvin presence spec to add definition for Client-Id
to support overloaded clients (multiple clients for the same user).  I've
expanded Section 3.8 to outline the approach for resolving overloading using
Client-Id and Status and updated the examples.  The changes to version 0.3.1
are highlighed in green.

Even better, I've also finished a initial implementation of the spec in the
form of a set of Java components, which I would not presume to call a
'reference' implementation ;)  It implements the overloading approach
described in the spec as well as being able to monitor multiple groups
and/or users and read/write extended ("x-") properties.  I've also
integrated the components into a presence client applet that can be used for
testing purposes.

The JAR can be found at ftp://203.5.217.35/pub/sticker/presence.jar.  The
test app can be running either by double-clicking the JAR or running "java
-jar presence.jar ".  The sources for the presence components are
also in the JAR, along with some javadoc.

For Java developers: I've taken care that the components are reasonably
straightforward to use and the back end components can be used independently
of Swing or Sticker.  The documentation at the head of
test/elvin/presence/PresenceClientPanel.java explains the design.

Cheers,

Matthew.

 <> 

PS. I'll be in Brisbane Dec 12-14 for the CDSA conference - hope to see a
few of you there.

Title: Elvin Presence Protocol








Elvin
Presence Protocol

Matthew Phillips


Draft 0.4 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 11/12/2001)

 

Contents

 TOC \o "2-2" \h \z \t "Heading
1,1" Notes About This Document  PAGEREF _Toc532708245 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200340035000000


1      Aim    PAGEREF _Toc532708246 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200340036000000


2        Requirements   PAGEREF _Toc532708247 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200340037000000


3        Specification   PAGEREF _Toc532708248 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200340038000000


3.1       User
Identity   PAGEREF _Toc532708249 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200340039000000


3.2       Groups.  PAGEREF _Toc532708250 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350030000000


3.3            Operation   PAGEREF _Toc532708251 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350031000000


3.4            Example
Exchange   PAGEREF _Toc532708252 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350032000000


3.5            Example
With Multiple Groups   PAGEREF _Toc532708253 \h 4
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350033000000


3.6            Presence
Request Fields   PAGEREF _Toc532708254 \h 5
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350034000000


3.7            Presence
Info Fields   PAGEREF _Toc532708255 \h 5
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350035000000


3.8            Handling
Conflicting Presence-Info Responses   PAGEREF _Toc532708256 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350036000000


3.9       Notes.  PAGEREF _Toc532708257 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350037000000


4        References   PAGEREF _Toc532708258 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350038000000


4.1       Other
Presence Protocols   PAGEREF _Toc532708259 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003700300038003200350039000000


 

Notes About This Document

The key words
"MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", 
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in IETF RFC 2119.

Changes to the
previous 0.2 draft specification are highlighted in green.

1        
Aim

The aim of the presence protocol is to provide a simple
and flexible means for Elvin users to communicate their presence online and
publish information they may wish to have known about themselves.

2        
Requirements

Presence services are already provided to a greater or
lesser extent by a number of applications, including ‘finger’, CoffeeBiff and
various Instant Messaging (IM) clients such as Jabber and ICQ.  The primary reasons for, and advantages of,
providing presence information via the Elvin presence protocol are:


·       
Does not require centralised, persistent state.


·       
Simple and thus easy to support.


·       
Separate, but complementary to, ticker messaging.


·       
Extensible.

3        
Specification

This section describes the protocol, including the
operations between clients and the format of the presence notifications.

3.1       
User Identity

The presence protocol assumes that users are identified by
a combination of name and domain, both of which are
case-insensitive strings containing any character except ‘@’.  The combination of name@domain
forms a unique user ID for the user in ‘presence space’ in the same
manner as an email address.

3.2       
Groups

A group is a namespace containing a set of online
users.  Every online user MUST be in at
least one group and may opt to be in several. 
All users within a group will be aware of each other’s presence by
default.  A group can be thought of as a
public, dynamic ‘buddy list’ that is automatically populated with community of
people.  When users want to add people
outside their main group to their buddy list, they have two options: explicitly
add the other user by name, or join the other group.

For example, all the people working in the Frob Testing
Division of Bob’s Frobs Inc, may elect to be in the ‘ftc.bobco’ group.   The manager of FTC might also elect to be
in the ‘management.bobco’ group so he or she can maintain contact with the
managers of other divisions.

As well as providing a way to partition presence
information into communities, the group concept is the key to scalability of
the presence protocol by making it efficient for clients to subscribe to all
presence info in a dynamic group smaller than the entire online world.

3.3       
Operation

The presence protocol
operates by exchanging two types of notifications:


·       
Presence-Info, and


·       
Presence-Request

Clients use Presence-Info notifications to publish
presence information about themselves, and use Presence-Request to trigger
other clients to generate info notifications.

Clients subscribe to Presence-Request notifications, and
generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up
and when any of the presence information previously published has changed.  A number of fields in Presence-Info are
optional, meaning they may be left out when their values are the same as they
were in the last full notification.

3.4       
Example Exchange

Note: see sections 3.6
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000
 & 3.7
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000
 for definitions of the Presence-Request and
Presence-Info notifications.

Scenario: Zaphod@hitch-hikers is already online.  Frodo@hitch-hikers, starts up a
presence-capable client.  Both are in
the ‘hitch-hikers’ group.

Frodo initially announces
he is online with the following full presence info notification:


    Presence-Info: initial
Presence-Protocol: 1000
        Client-Id: ffffff-111111
             User: Frodo@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Zaphod’s client, being subscribed to presence info in for
the hitch-hikers group, receives the information about Frodo and updates its
registry.

Frodo’s client now populates its registry by:


1.     
Subscribing to presence information for the hitch-hikers group
using the expression:
require
(Presence-Info) && 
    contains
(fold-case (Groups), “|hitch-hikers|”)


2.     
Sending a request for presence information about people in the
current group.  The presence request
notification Frodo sends is:

 Presence-Request: cafebabe12345
Presence-Protocol: 1000 
         Reqestor: Frodo@hitch-hikers
           Groups: |hitch-hikers|
            Users: *

All clients in the group, including Zaphod’s, receive the
request since they have subscribed using an expression like:

Require (Presence-Request) &&
  (contains (fold-case (Groups),
“|hitch-hikers|”) ||
   contains (fold-case (Users),
“|zaphod@hitch-hikers|”))

Zaphod’s client responds with a full presence info
notification tagged with the request ID from Frodo’s message:


    Presence-Info: cafebabe12345
Presence-Protocol: 1000
        Client-Id: zz9pza-222222
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online (going for
coffee at 3pm)
  Status-Duration: 42
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: zticker 3.0
x-Number-Of-Heads: 2

Frodo’s client updates its registry, at which point
Zaphod, Frodo, and any other interested clients are in sync.

Later, when Zaphod decides to go for coffee, he hits the
“Coffee!” button on his client, which sends this partial presence notification:

    Presence-Info: update
Presence-Protocol: 1000
        Client-Id: zz9pza-222222
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: unavailable
      Status-Text: Coffee!
  Status-Duration: 0

3.5       
Example With Multiple Groups

The previous example assumed Frodo was in a single
group.  The following example (shown
from Frodo’s end only) illustrates how his client would support Frodo being
both in the ‘hitch-hikers’ group and the ‘hobbits’ group.  The key changes from the previous example
are highlighted in bold.

Frodo’s client would announce he is online with:


    Presence-Info: initial
Presence-Protocol: 1000
        Client-Id: ffffff-111111
             User: Frodo@hitch-hikers
           Groups:
|hitch-hikers|hobbits|
           Status: online
     
Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Frodo’s client subscribes to Presence-Request’s using this
expression:

require (Presence-Request) &&
  contains (fold-case (Groups),
     “|hitch-hikers|”, “|hobbits|”) ||
  contains (fold-case (Users), “|frodo@hitch-hikers|”)







3.6       
Presence Request Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
  
   
   Presence-Request
   
   
   String
   
   
   Marks the notification as a presence request and
   carries a request ID.
   
   
   A random, unique request ID, not longer than 255
   characters, no spaces.  The ID MUST
   NOT be “initial” or “update”.
   
   
   Always
   
  
  
   
   Presence-Protocol
   
   
   Int32
   
   
   Same as Presence-Info
   
   
    
   
   
   Always
   
  
  
   
   Requestor
   
   
   String
   
   
   The username of the person requesting the presence
   information.
   
   
   A username in user@domain form.
   
   
   Optional
   
  
  
   
   Groups
   
   
   String
   
   
   Allows a client to request status info of all users in
   a set of groups.  Clients should respond to requests when
   this field contains a group the user is a member of.
   
   
   A set of groups in the same format as Presence-Info.
   or  “*’ when the User field contains
   a specific username.
   The User and Groups fields MUST NOT both be “*”.  If no groups are being requested, this
   field should be left empty.
   
   
   Always
   
  
  
   
   Users
   
   
   String
   
   
   Allows a client to request status info of particular
   users. Clients should respond to requests when the “Users” field contains
   their username.
   
   
   A set of usernames delimited by “|” or “*” (any user).
   Eg “|frodo@home|bob@bobco”.
   The
   User and Groups fields MUST NOT both be “*”.  If no specific users are being requested,
   this field should be left empty.
   
   
   Always
   
  
 


 

3.7       
Presence Info Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
 
 
  
  Presence-Info
  
  
  String
  
  
  Marks this as a presence info notification and specifies
  its subtype
  
  
  
·       
  “initial”: Full info, with all fields that the client
  supports populated.  Generated when
  the client starts and broadcasts initial presence info.
  
·       
  “request_id”: Full info (all fields that the
  client supports are populated) in response to a Presence-Request with ID request_id.
  
·       
  “update”: Partial info, with only the optional fields
  that have changed since last update included.  Generated when presence data (eg Status-Text) changes.
  
  

  Always
  
 
 
  
  Presence-Protocol
  
  
  Int32
  
  
  The version of the presence protocol that is used in
  this notification.
  
  
   major_version
  * 1000 + minor_version.  Eg.
  2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for
  major/minor versions apply: major version number changes indicate
  incompatible changes to the protocol, minor number increments indicate
  backward-compatible changes to the protocol.
  
  
  Always
  
 
 
  
  Client-Id
  
  
  String
  
  
  Identifies
  the client instance
  that generated
  the response.  This can be used by receivers
  to resolve conflicting
  presence information from users that are running multiple clients -
  see section  REF _Ref527966988 \r \h 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for more information.
  
  
  Any
  string that uniquely identifies the client and which remains constant across the period between client initialisation (sending the first presence response) and client shutdown (sending an “offline” status
  notification).
  
  
  Always
  
 
 
  
  User
  
  
  String
  
  
  The user’s username.
  
  
  Any username: eg “mpp@dsto”, “bob@bobco”, etc.
  
  
  Always
  
 
 
  
  Groups
  
  
  String
  
  
  The groups the user is a member of.
  
  
  A set of group names separated by ‘|’.
  For example “|dsto|quake heroes|”.
  Note that the preceding and trailing ‘|’s allow clients to use the ‘contains’
  function to easily test for particular groups without having to handle three
  cases (where the group is at the beginning, middle and end of the list).
  
  
  Always
  
 
 
  
  Status
  
  
  String
  
  
  The status of the user.
  
  
  
·       
  “online”: the user is online and ready to receive
  messages.
  
· “unavailable”: the user is
  not currently viewing messages (eg away from desk).
  
·       
  “unavailable?”: the client has made an educated guess
  that the user is unavailable.  This is
  often the result of the client not seeing any keystroke or mouse activity
  from the user for a given period of time.
  
·       
  “unavailable”: the user is not currently viewing
  messages (eg away from desk).
  
·       
   “offline”:
  the user has disconnected.  This is
  usually sent when a presence client shuts down, but may be sent whenever the
  user no longer “exists” (eg if the user changes their name).
  
·       
   “coffee”: the
  user is on a coffee break.  This
  special status, which is functionally equivalent to “unavailable”, is
  intended to support CoffeeBiff-style client interactions.
  The “online”, “offline” and “unavailable” status settings
  SHOULD be taken into account by the client when merging conflicting
  notifications: see section 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for a discussion on this.
  
  

  Optional
  
 
 
  
  Status-Text
  
  
  String
  
  
  Text describing the status of the user.
  
  
  Any string intended to be displayed as the current
  status eg “Online: but will be away this afternoon”.
   
  
  
  Optional: required when the Status field is present
  
 
 
  
  Status-Duration
  
  
  Int32
  
  
  The amount of time (in seconds) that the current status
  has been in effect.  This is a
  relative duration rather than an absolute time since the status was set to
  avoid the perennial problems with inaccurate clocks and time zones.
  
  
  Any integer >= 0. 
  Undefined behaviour if anyone holds the same status longer than 136
  years ;) (232 seconds)
  
  
  Optional: required when Status field is present
  
 
 
  
  Chat-Groups
  
  
  String
  
  
  The set of chat groups the user is subscribed to.
  
  
  Eg. “|Chat|ticker-dev|”
  
  
  Optional
  
 
 
  
  News-Groups
  
  
  String
  
  
  The set of news groups the user is subscribed to.
  
  
  Eg. “|BreakingStories|Slashdot|”
  
  
  Optional
  
 
 
  
  Ticker-Client
  
  
  String
  
  
  The ticker client the user is running
  
  
  A ticker client name and version eg “sticker 2.0.1”,
  “xtickertape 2.0a”.  A missing value
  indicates the user is not running a ticker client.  Users that are running ticker but which don’t wish the type of
  client to be known should use “generic”.
  
  
  Optional
  
 










3.8       
Handling Conflicting Presence-Info Responses

Clients SHOULD handle the situation where multiple
“overloaded”
Presence-Info responses are received for single user by using the Client-Id and
Status fields.  For example, in the case
where a user is running two clients on two hosts, one of which is listing the
user as “unavailable?”, the other which lists the user as “online”,
Presence-Request’s will generate two responses with two different
Client-Id’s.  In this case, clients
SHOULD give precedence to the information in the “online” notification response
over the “unavailable?”.

A straightforward way of
achieving this is for clients to maintain a registry of users that assigns to
each unique User a set of received Presence-Info’s,
one per unique Client-Id.  For each
user, the client selects the Presence-Info with the “most active” status as the
authoritative info for that user.  In the case where all statuses are equal,
the client selects the Presence-Info with the smallest Status-Duration.  The order of precedence for the Status field (from “most active” to “most
inactive”) is “online”,  “unavailable?”, “unavailable” and “offline”,
with any other (illegal) statuses being considered to fall between
“unavailable” and “offline” (ie offline is the “most inactive” state a user can
be in).

3.9       
Notes


·       
Presence-Info: the values of this field have been
designed so that clients can easily discern the derivation of updates if they
wish (for efficiency or otherwise). 
However, clients are not required to distinguish between the different
types of Status-InfoPresence-Info
notification: simply updating a registry with the new data in any Presence-Info
notification is sufficient, so long as missing optional fields are handled.

Note that one possible efficiency enabled by this approach is the ability to
opt out of redundant “reply” updates in response to a Presence-Request from
other clients, using the expression Status-InfoPresence-Info != “replyupdate” &&
Presence-Info != “initial”.  The other obvious way to mark replies to
status requests -- with a separate “In-Reply-To” field -- makes this difficult,
since !require
(In-Reply-To) can’t be used to create the same effect due to the
tri-state logic used in the Elvin subscription language.


·       
Presence-Protocol: this is designed so that clients can
subscribe to known protocol sets eg “Protocol-Version >= 1000 &&
Protocol-Version < 3000” picks up any 1.x or 2.x protocol
notifications.


·       
It is assumed that, if the user is running a ticker
client, then they are subscribed to their ‘personal’ chat group with the same
name as their user ID ie “user@domain”. 
This convention makes it obvious how to send a ticker message to someone
visible via the presence system.


·       
Non-standard fields should use the “x-” naming
convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to
display the non-standard fields.


·       
Treating usernames or groups as case-sensitive runs the
risk of people not seeing each other because they got the case wrong eg I look
for ‘bob@bobco’ and fail to see him because he is really ‘Bob@BobCo’.


·       
Requestor field: this was initially intended to allow
clients to respond differently depending on the requestor, eg subscriptions to
some groups might be hidden except to certain people.  But since any client can listen in to the replies, it would not
be a particularly useful way of hiding information (using the security API’s
would make more sense).  It is left in
the specification but made optional.

4        
References

4.1       
Other Presence Protocols

Thanks to David Arnold for providing the initial set of
links that these references are based on.

4.1.1       
Simple General Awareness Protocol (SGAP)

A Lotus-sponsored IETF
Internet Draft, which expired on May 98. 
It’s not clear if this is still a live project.  Specification talks mainly about
client/server interactions and message formats.  Seems to offer little wisdom for this specification.

Also see Lotus
Research Page for more information.

4.1.2       
Instant Messaging and Presence Protocol (IMPP)

Uses presence information messages (MIME type
message/cpim) that contain an XML presence info ‘payload’.

Example payload (from IMPP
internet draft):

                         open                     away                       im:shingo@jp.fujitsu.com       I'll be in Tokyo tomorrow                          open              mailto:shingo@jp.fujitsu.com           

 

The main wisdom to be gained here is that the presence
info is divided into one or more contact tuples, which describe the users’
status in a particular online medium. 
In the example, the user is saying they have both Instant Messaging and email
contacts, but are not online for IM. 
The addition of the note to the IM tuple presumably informs interested
parties that the person will be available for chat the next day.  The Status-Text field of this protocol gives
some of this functionality, but we are really assuming that ticker is the main
messaging method.  Email addresses and
other info can be supplied as an “x-” field.

For more info see IMPP charter page,
IMPP main page, IMPP working group pages and
Lotus
Research.

4.1.3       
Jabber

Jabber is an IM/presence service built from a series of
federated servers.  The protocol is open
and there are a number of open-source clients. 
A free trialware server for up to 100 users is available, but a
commercial license is needed for larger numbers of users.

The XML-based Jabber protocol
includes a presence message type. 
Example (from protocol page):

      Stay but a little, I will come again.    away   

The distinction between
‘show’ and ‘status’ is interesting. 
Status is user-readable text and is used in the same way the protocol in
this document.  ‘Show’ can be:



 
  

  chat
  
  
  The client is available for immediate contact.
  
 
 
  
  away
  
  
  The client is online, but is momentarily away (e.g., at lunch or a
  meeting).
  
 
 
  
  xa
  
  
  The client is online, but has been inactive for a long time.
  
 
 
  
  dnd
  
  
  The client is in Do Not Disturb mode.
  
 


The Elvin presence protocol
currently overloads show and status into the ‘Status’ field eg
“Unavailable (at meeting in rm 56)” is the same as Jabber show = “away” +
status = “at meeting in rm 56”.  We may
want to consider following the Jabber example.

Jabber also has an “iq” message format can be used to
exchange extended information.

See home page, main commercial page, Jabber Central news page

4.1.4       
ICQ

The ICQ
v5 protocol allows a range of, non-extensible (?) information about a user
to be published using the CMD_META_USER message such as name, phone, age, city
etc.  This sort of information could be
accommodated by the Elvin presence protocol using x-Name, x-Phone etc.

See ICQ
protocol site.








From arnold at dstc.monash.edu.au  Thu Dec 13 02:53:52 2001
From: arnold at dstc.monash.edu.au (David Arnold)
Date: Tue Oct 14 08:01:41 2003
Subject: [ticker-dev] Presence specification draft 0.4
In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EC29@salex005.dsto.defence.gov.au>
Message-ID: <200112121654.fBCGs57m013251@xevious.dstc.monash.edu.au>


-->"Matthew" == Phillips, Matthew  writes:

  Matthew> due to lack of any opposition and finally getting some free
  Matthew> time for fun stuff, I've updated the Elvin presence spec to
  Matthew> add definition for Client-Id to support overloaded clients
  Matthew> (multiple clients for the same user).  

thanks for the update Matthew.

i have a few remaining issues with this latest draft:

1. i'd like to see some clarification (somewhere in 3.1 or 3.2?) of
   the differences between the user's domain and groups.  is the
   domain basically just another group (in terms of subscriptions)?

2. the table entry for "Status" in 3.7 still provides "coffee" as a
   valid status, but the discussion in 3.8 does not mention it (and
   actually declares anything it doesn't mention as illegal).

   i think, following the separation of status and status-text, that a
   coffee status is not needed anymore?

3. can we add a User-Agent field to Presence-Info?  i know it could be
   done as x-User-Agent, but perhaps it's sufficiently common for
   standardisation?

4. there's no discussion of security issues in the draft so far.

   i've been thinking about this, and the most disruptive thing i've
   considered so far is that there might be a need to have different
   visibility for different groups, requiring multiple notifications
   for a single presence event.

   for example, if i'm prepared to reveal my subscribed ticker group
   list to some people/groups, but not to others, then i might need to
   send two notifications for each presence event, keyed
   appropriately, one without the Chat-Groups.

   this then introduces the possibility that some clients could get
   multiple notifications for a single presence event.  this might not
   be a big deal, but perhaps we want to identify events, so that
   clients can at least *detect* that the second and subsequent
   notifications refer to the same event?


i'll be releasing a new, 0.4-compliant, version of epm shortly.





d



From Matthew.Phillips at dsto.defence.gov.au  Mon Dec 17 16:01:10 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:41 2003
Subject: [ticker-dev] Presence specification draft 0.4
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EC3E@salex005.dsto.defence.gov.au>


> i have a few remaining issues with this latest draft:
> 
> 1. i'd like to see some clarification (somewhere in 3.1 or 3.2?) of
>    the differences between the user's domain and groups.  is the
>    domain basically just another group (in terms of subscriptions)?

Good point.  I really intend that the domain simply be a namespace for
separating usernames in the same fashion as email domains.  I'll also add
that presence clients MAY put the user into a presence group with the same
name as their domain as a convention, but that there is no requirement for
this as part of the protocol spec.

> 2. the table entry for "Status" in 3.7 still provides "coffee" as a
>    valid status, but the discussion in 3.8 does not mention it (and
>    actually declares anything it doesn't mention as illegal).
> 
>    i think, following the separation of status and status-text, that a
>    coffee status is not needed anymore?

You're right in that "coffee" is not strictly needed, but it might be useful
for clients/bots that want to interpret coffee break events, for which
scanning the status text for the word coffee would be a lesser substitute.
As mentioned in the spec, it's really only there so that presence info can
subsume CoffeeBiff.   I have no problems with either taking it out, or
leaving it in and fixing the list in 3.8.

> 3. can we add a User-Agent field to Presence-Info?  i know it could be
>    done as x-User-Agent, but perhaps it's sufficiently common for
>    standardisation?

Shouldn't be too controversial, I'll add it in.

> 4. there's no discussion of security issues in the draft so far.
> 
>    i've been thinking about this, and the most disruptive thing i've
>    considered so far is that there might be a need to have different
>    visibility for different groups, requiring multiple notifications
>    for a single presence event.
> 
>    for example, if i'm prepared to reveal my subscribed ticker group
>    list to some people/groups, but not to others, then i might need to
>    send two notifications for each presence event, keyed
>    appropriately, one without the Chat-Groups.
> 
>    this then introduces the possibility that some clients could get
>    multiple notifications for a single presence event.  this might not
>    be a big deal, but perhaps we want to identify events, so that
>    clients can at least *detect* that the second and subsequent
>    notifications refer to the same event?

This sort of multiple presence info situation won't be a problem so long as
clients don't treat the absence of a field as meaning an empty value for
that field.  With this convention, in the case where a 'trusted' client
receives two presence info's, one with and one without the Chat-Groups
field, the client will not erase the correct values for the chat groups if
it gets the partial info after the full info.  This is a fairly natural way
to implement presence info handling in any case, however I will add some
discussion to the spec to the effect that clients should treat a missing
field as meaning "same value as last notification".

Matt.



From Matthew.Phillips at dsto.defence.gov.au  Mon Dec 17 18:00:50 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:41 2003
Subject: Presence specification draft 0.4.1
Message-ID: <2149A0BABC77D311AF890090274E00B203A1EC41@salex005.dsto.defence.gov.au>

A (minor) update in response to David's comments.  Changes highlighted in
green as before.


Title: Elvin Presence Protocol








Elvin
Presence Protocol

Matthew Phillips


Draft 0.4.1 ( SAVEDATE \@ "d/MM/yyyy" \* MERGEFORMAT 17/12/2001)

 

Contents

 TOC \o "2-2" \h \z \t "Heading
1,1" Notes About This Document  PAGEREF _Toc532544818 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800310038000000


1      Aim    PAGEREF _Toc532544819 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800310039000000


2        Requirements   PAGEREF _Toc532544820 \h 1
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320030000000


3        Specification   PAGEREF _Toc532544821 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320031000000


3.1       User
Identity   PAGEREF _Toc532544822 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320032000000


3.2       Groups.  PAGEREF _Toc532544823 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320033000000


3.3            Operation   PAGEREF _Toc532544824 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320034000000


3.4            Example
Exchange   PAGEREF _Toc532544825 \h 2
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320035000000


3.5            Example
With Multiple Groups   PAGEREF _Toc532544826 \h 4
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320036000000


3.6            Presence
Request Fields   PAGEREF _Toc532544827 \h 5
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320037000000


3.7            Presence
Info Fields   PAGEREF _Toc532544828 \h 5
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320038000000


3.8            Handling
Conflicting Presence-Info Responses   PAGEREF _Toc532544829 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800320039000000


3.9       Notes.  PAGEREF _Toc532544830 \h 10
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800330030000000


4        References   PAGEREF _Toc532544831 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800330031000000


4.1       Other
Presence Protocols   PAGEREF _Toc532544832 \h 11
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F0054006F0063003500330032003500340034003800330032000000


 

Notes About This Document

The key words
"MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", 
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in IETF RFC 2119.

Changes to the
previous 0.2 draft specification are highlighted in green.


1        
Aim

The aim of the presence protocol is to provide a simple
and flexible means for Elvin users to communicate their presence online and
publish information they may wish to have known about themselves.


2        
Requirements

Presence services are already provided to a greater or
lesser extent by a number of applications, including ‘finger’, CoffeeBiff and
various Instant Messaging (IM) clients such as Jabber and ICQ.  The primary reasons for, and advantages of,
providing presence information via the Elvin presence protocol are:


·       
Does not require centralised, persistent state.


·       
Simple and thus easy to support.


·       
Separate, but complementary to, ticker messaging.


·       
Extensible.


3        
Specification

This section describes the protocol, including the
operations between clients and the format of the presence notifications.


3.1       
User Identity

The presence protocol assumes that users are identified by
a combination of name and domain, both of which are
case-insensitive strings containing any character except ‘@’.  The combination of name@domain
forms a unique user ID for the user in ‘presence space’ in the same
manner as an email address.  Apart from
its role as a namespace, the domain plays no other role in the
presence protocol.


3.2       
Presence Groups

A group is a namespace containing a set of online
users.  Every online user MUST be in at
least one group and may opt to be in several. 
All users within a group will be aware of each other’s presence by
default.  A group can be thought of as a
public, dynamic ‘buddy list’ that is automatically populated with community of
people.  When users want to add people
outside their main group to their buddy list, they have two options: explicitly
add the other user by name, or join the other group.

For example, all the people working in the Frob Testing
Division of Bob’s Frobs Inc, may elect to be in the ‘ftc.bobco’ group.   The manager of FTC might also elect to be
in the ‘management.bobco’ group so he or she can maintain contact with the
managers of other divisions.

As well as providing a way to partition presence
information into communities, the group concept is the key to scalability of
the presence protocol by making it efficient for clients to subscribe to all
presence info in a dynamic group smaller than the entire online world.


3.3       
Operation

The presence protocol
operates by exchanging two types of notifications:


·       
Presence-Info, and


·       
Presence-Request

Clients use Presence-Info notifications to publish
presence information about themselves, and use Presence-Request to trigger
other clients to generate info notifications.

Clients subscribe to Presence-Request notifications, and
generate Presence-Info notifications in response.  Clients also spontaneously emit Presence-Info when they start up
and when any of the presence information previously published has changed.  


A number of fields in
Presence-Info are optional, meaning they may be left out when their values are
the same as they were in the last full notification.  In general, clients should never assume that any of the
optional fields in a presence notification will be present, and
should treat a missing field as indicating the value of that field is the same as when it was
specified previously.


3.4       
Example Exchange

Note: see sections 3.6
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340037000000
 & 3.7
 08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320035003600330034003400340038000000
 for definitions of the Presence-Request and
Presence-Info notifications.

Scenario: Zaphod@hitch-hikers is already online.  Frodo@hitch-hikers, starts up a
presence-capable client.  Both are in
the ‘hitch-hikers’ group.

Frodo initially announces
he is online with the following full presence info notification:


    Presence-Info: initial
Presence-Protocol: 1000
        Client-Id: ffffff-111111
             User: Frodo@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Zaphod’s client, being subscribed to presence info in for
the hitch-hikers group, receives the information about Frodo and updates its
registry.

Frodo’s client now populates its registry by:


1.     
Subscribing to presence information for the hitch-hikers group
using the expression:
require
(Presence-Info) && 
    contains (fold-case
(Groups), “|hitch-hikers|”)


2.     
Sending a request for presence information about people in the
current group.  The presence request
notification Frodo sends is:

 Presence-Request: cafebabe12345
Presence-Protocol: 1000 
         Reqestor: Frodo@hitch-hikers
           Groups: |hitch-hikers|
            Users: 

All clients in the group, including Zaphod’s, receive the
request since they have subscribed using an expression like:

Require (Presence-Request) &&
  (contains (fold-case (Groups),
“|hitch-hikers|”) ||
   contains (fold-case (Users),
“|zaphod@hitch-hikers|”))

Zaphod’s client responds with a full presence info
notification tagged with the request ID from Frodo’s message:


    Presence-Info: cafebabe12345
Presence-Protocol: 1000
        Client-Id:      zz9pza-222222
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: online
      Status-Text: Online (going for
coffee at 3pm)
  Status-Duration: 42
      Chat-Groups: |Chat|ticker-dev|
      News-Groups: |BreakingStories|Slashdot|
    Ticker-Client: zticker 3.0
x-Number-Of-Heads: 2

Frodo’s client updates its registry, at which point
Zaphod, Frodo, and any other interested clients are in sync.

Later, when Zaphod decides to go for coffee, he hits the
“Coffee!” button on his client, which sends this partial presence notification:

    Presence-Info: update
Presence-Protocol: 1000
        Client-Id: zz9pza-222222
             User: Zaphod@hitch-hikers
           Groups: |hitch-hikers|
           Status: unavailable
      Status-Text: Coffee!
  Status-Duration: 0


3.5       
Example With Multiple Groups

The previous example assumed Frodo was in a single
group.  The following example (shown
from Frodo’s end only) illustrates how his client would support Frodo being
both in the ‘hitch-hikers’ group and the ‘hobbits’ group.  The key changes from the previous example
are highlighted in bold.

Frodo’s client would announce he is online with:


    Presence-Info: initial
Presence-Protocol: 1000
        Client-Id: ffffff-111111
             User: Frodo@hitch-hikers
           Groups:
|hitch-hikers|hobbits|
           Status: online
      Status-Text: Online
  Status-Duration: 0
      Chat-Groups: |Chat|ticker-dev|
      News-Groups:
|BreakingStories|Slashdot|
    Ticker-Client: frodoticker 1.0

Frodo’s client subscribes to Presence-Request’s using this
expression:

require (Presence-Request) &&
  contains (fold-case (Groups),
     “|hitch-hikers|”, “|hobbits|”) ||
  contains (fold-case (Users), “|frodo@hitch-hikers|”)







3.6       
Presence Request Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
  
   
   Presence-Request
   
   
   String
   
   
   Marks the notification as a presence request and
   carries a request ID.
   
   
   A random, unique request ID, not longer than 255
   characters, no spaces.  The ID MUST
   NOT be “initial” or “update”.
   
   
   Always
   
  
  
   
   Presence-Protocol
   
   
   Int32
   
   
   Same as Presence-Info
   
   
    
   
   
   Always
   
  
  
   
   Requestor
   
   
   String
   
   
   The username of the person requesting the presence
   information.
   
   
   A username in user@domain form.
   
   
   Optional
   
  
  
   
   Groups
   
   
   String
   
   
   Allows a client to request status info of all users in
   a set of groups.  Clients should
   respond to requests when this field contains a group the user is a member
   of.
   
   
   A set of groups in the same format as
   Presence-Info.  If no groups are
   being requested, this field should be left empty.
   
   
   Always
   
  
  
   
   Users
   
   
   String
   
   
   Allows a client to request status info of particular
   users. Clients should respond to requests when the “Users” field contains
   their username.
   
   
   A set of usernames delimited by “|”.
   Eg “|frodo@home|bob@bobco”.  If no
   specific users are being requested, this field should be left empty.
   
   
   Always
   
  
 


 


3.7       
Presence Info Fields



 
  
   

   Field
   
   
   Type
   
   
   Description
   
   
   Possible values
   
   
   When Used
   
  
 
 
  
  Presence-Info
  
  
  String
  
  
  Marks this as a presence info notification and specifies
  its subtype
  
  
  
·       
  “initial”: Full info, with all fields that the client
  supports populated.  Generated when
  the client starts and broadcasts initial presence info.
  
·       
  “request_id”: Full info (all fields that the
  client supports are populated) in response to a Presence-Request with ID request_id.
  
·       
  “update”: Partial info, with only the optional fields
  that have changed since last update included.  Generated when presence data (eg Status-Text) changes.
  
  

  Always
  
 
 
  
  Presence-Protocol
  
  
  Int32
  
  
  The version of the presence protocol that is used in
  this notification.
  
  
   major_version
  * 1000 + minor_version.  Eg.
  2001 = version 2.1 of the protocol, 3093 = version 3.93 of the protocol.  The usual compatibility rules for
  major/minor versions apply: major version number changes indicate
  incompatible changes to the protocol, minor number increments indicate
  backward-compatible changes to the protocol.
  
  
  Always
  
 
 
  
  Client-Id
  
  
  String
  
  
  Identifies the client instance that generated the
  response.  This can be used by
  receivers to resolve conflicting presence information from users that are
  running multiple clients - see section 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for more information.
  
  
  Any string that uniquely identifies the client and which
  remains constant across the period between client initialisation (sending the
  first presence response) and client shutdown (sending an “offline” status
  notification).
  
  
  Always
  
 
 
  
  User
  
  
  String
  
  
  The user’s username.
  
  
  Any username: eg “mpp@dsto”, “bob@bobco”, etc.
  
  
  Always
  
 
 
  
  Groups
  
  
  String
  
  
  The groups the user is a member of.
  
  
  A set of group names separated by ‘|’.
  For example “|dsto|quake heroes|”.
  Note that the preceding and trailing ‘|’s allow clients to use the ‘contains’
  function to easily test for particular groups without having to handle three
  cases (where the group is at the beginning, middle and end of the list).
  
  
  Always
  
 
 
  
  Status
  
  
  String
  
  
  The status of the user.
  
  
  
·       
  “online”: the user is online and ready to receive
  messages.
  
·       
  “unavailable?”: the client has made an educated guess
  that the user is unavailable.  This is
  often the result of the client not seeing any keystroke or mouse activity
  from the user for a given period of time.
  
·       
  “unavailable”: the user is not currently viewing
  messages (eg away from desk).
  
·       
  “offline”: the user has disconnected.  This is usually sent when a presence
  client shuts down, but may be sent whenever the user no longer “exists” (eg
  if the user changes their name).
  
·       
  “coffee”: the user is on a coffee break.  This special status, which is functionally
  equivalent to “unavailable”, is intended to support CoffeeBiff-style client
  interactions.
  The status settings SHOULD be taken into account by the
  client when merging conflicting notifications: see section 3.8
   08D0C9EA79F9BACE118C8200AA004BA90B02000000080000000E0000005F005200650066003500320037003900360036003900380038000000
   for a discussion on this.
  
  

  Optional
  
 
 
  
  Status-Text
  
  
  String
  
  
  Text describing the status of the user.
  
  
  Any string intended to be displayed as the current
  status eg “Online: but will be away this afternoon”.
   
  
  
  Optional: required when the Status field is present
  
 
 
  
  Status-Duration
  
  
  Int32
  
  
  The amount of time (in seconds) that the current status
  has been in effect.  This is a
  relative duration rather than an absolute time since the status was set to
  avoid the perennial problems with inaccurate clocks and time zones.
  
  
  Any integer >= 0. 
  Undefined behaviour if anyone holds the same status longer than 136
  years ;) (232 seconds)
  
  
  Optional: required when Status field is present
  
 
 
  
  Chat-Groups
  
  
  String
  
  
  The set of chat groups the user is subscribed to.
  
  
  Eg. “|Chat|ticker-dev|”
  
  
  Optional
  
 
 
  
  News-Groups
  
  
  String
  
  
  The set of news groups the user is subscribed to.
  
  
  Eg. “|BreakingStories|Slashdot|”
  
  
  Optional
  
 
 
  
  Ticker-Client
  
  
  String
  
  
  The ticker client the user is running
  
  
  A ticker client name and version eg “sticker 2.0.1”,
  “xtickertape 2.0a”.  A missing value
  indicates the user is not running a ticker client.  Users that are running ticker but which don’t wish the type of
  client to be known should use “generic”.
  
  
  Optional
  
 
 
  
  User-Agent
  
  
  String
  
  
  The name of the presence client that generated
  this notification.
  
  
  Any string value identifying a presence client,
  or “generic” if this information is being hidden.
  
  
  Optional
  
 










3.8       
Handling Conflicting Presence-Info Responses

Clients SHOULD
handle the situation where multiple “overloaded” Presence-Info responses are
received for single user by using the Client-Id and Status fields.  For example, in the case where a user is
running two clients on two hosts, one of which is listing the user as
“unavailable?”, the other which lists the user as “online”, Presence-Request’s
will generate two responses with two different Client-Id’s.  In this case, clients SHOULD give precedence
to the information in the “online” notification response over the “unavailable?”.

A straightforward
way of achieving this is for clients to maintain a registry of users that
assigns to each unique User a set of received Presence-Info’s, one per unique
Client-Id.  For each user, the client
selects the Presence-Info with the “most active” status as the authoritative
info for that user.  In the case where
all statuses are equal, the client selects the Presence-Info with the smallest
Status-Duration.  The order of
precedence for the Status field (from “most active” to “most inactive”) is
“online”,  “unavailable?”, “unavailable”, “coffee” and
“offline”, with any other (illegal) statuses being considered to fall between
“unavailable” and “offline” (ie offline is the “most inactive” state a user can
be in).


3.9       
Notes


·       
Presence-Info: the values of this field have been
designed so that clients can easily discern the derivation of updates if they
wish (for efficiency or otherwise). 
However, clients are not required to distinguish between the different
types of Presence-Info notification: simply updating a registry with the new
data in any Presence-Info notification is sufficient, so long as missing
optional fields are handled.

Note that one possible efficiency enabled by this approach is the ability to
opt out of redundant “reply” updates in response to a Presence-Request from
other clients, using the expression Presence-Info != “update”
&& Presence-Info != “initial”.  The other obvious way to mark replies to status requests -- with
a separate “In-Reply-To” field -- makes this difficult, since !require
(In-Reply-To) can’t be used to create the same effect due to the
tri-state logic used in the Elvin subscription language.


·       
Presence-Protocol: this is designed so that clients can
subscribe to known protocol sets eg “Protocol-Version >= 1000 &&
Protocol-Version < 3000” picks up any 1.x or 2.x protocol
notifications.


·       
It is assumed that, if the user is running a ticker
client, then they are subscribed to their ‘personal’ chat group with the same
name as their user ID ie “user@domain”. 
This convention makes it obvious how to send a ticker message to someone
visible via the presence system.


·       
Non-standard fields should use the “x-” naming
convention eg “x-Phone-Number”, “x-Organisation”, etc.  Ideally, clients should provide an option to
display the non-standard fields.


·       
Treating usernames or groups as case-sensitive runs the
risk of people not seeing each other because they got the case wrong eg I look
for ‘bob@bobco’ and fail to see him because he is really ‘Bob@BobCo’.


·       
Requestor field: this was initially intended to allow
clients to respond differently depending on the requestor, eg subscriptions to
some groups might be hidden except to certain people.  But since any client can listen in to the replies, it would not
be a particularly useful way of hiding information (using the security API’s
would make more sense).  It is left in
the specification but made optional.


4        
References


4.1       
Other Presence Protocols

Thanks to David Arnold for providing the initial set of
links that these references are based on.


4.1.1       
Simple General Awareness Protocol (SGAP)

A Lotus-sponsored IETF
Internet Draft, which expired on May 98. 
It’s not clear if this is still a live project.  Specification talks mainly about
client/server interactions and message formats.  Seems to offer little wisdom for this specification.

Also see Lotus
Research Page for more information.


4.1.2       
Instant Messaging and Presence Protocol (IMPP)

Uses presence information messages (MIME type
message/cpim) that contain an XML presence info ‘payload’.

Example payload (from IMPP
internet draft):

                         open                     away                       im:shingo@jp.fujitsu.com       I'll be in Tokyo tomorrow                          open              mailto:shingo@jp.fujitsu.com           

 

The main wisdom to be gained here is that the presence info
is divided into one or more contact tuples, which describe the users’ status in
a particular online medium.  In the
example, the user is saying they have both Instant Messaging and email
contacts, but are not online for IM. 
The addition of the note to the IM tuple presumably informs interested
parties that the person will be available for chat the next day.  The Status-Text field of this protocol gives
some of this functionality, but we are really assuming that ticker is the main
messaging method.  Email addresses and
other info can be supplied as an “x-” field.

For more info see IMPP charter page,
IMPP main page, IMPP working group pages and
Lotus
Research.


4.1.3       
Jabber

Jabber is an IM/presence service built from a series of
federated servers.  The protocol is open
and there are a number of open-source clients. 
A free trialware server for up to 100 users is available, but a
commercial license is needed for larger numbers of users.

The XML-based Jabber protocol
includes a presence message type. 
Example (from protocol page):

      Stay but a little, I will come again.    away   

The distinction between
‘show’ and ‘status’ is interesting. 
Status is user-readable text and is used in the same way the protocol in
this document.  ‘Show’ can be:



 
  

  chat
  
  
  The client is available for immediate contact.
  
 
 
  
  away
  
  
  The client is online, but is momentarily away (e.g., at lunch or a
  meeting).
  
 
 
  
  xa
  
  
  The client is online, but has been inactive for a long time.
  
 
 
  
  dnd
  
  
  The client is in Do Not Disturb mode.
  
 


The Elvin presence protocol
currently overloads show and status into the ‘Status’ field eg
“Unavailable (at meeting in rm 56)” is the same as Jabber show = “away” +
status = “at meeting in rm 56”.  We may
want to consider following the Jabber example.

Jabber also has an “iq” message format can be used to
exchange extended information.

See home page, main commercial page, Jabber Central news page


4.1.4       
ICQ

The ICQ
v5 protocol allows a range of, non-extensible (?) information about a user
to be published using the CMD_META_USER message such as name, phone, age, city
etc.  This sort of information could be
accommodated by the Elvin presence protocol using x-Name, x-Phone etc.

See ICQ
protocol site.








From sachink at dstc.edu.au  Tue Dec 18 16:34:38 2001
From: sachink at dstc.edu.au (Sachin Kulkarni)
Date: Tue Oct 14 08:01:41 2003
Subject: [ticker-dev] Presence specification draft 0.4.1
In-Reply-To: <2149A0BABC77D311AF890090274E00B203A1EC41@salex005.dsto.defence.gov.au>
Message-ID: <002901c1878e$12adf260$d2b16682@somepc210>


1. Re Section 3.7 -> Status. Do we need something like 'appear offline'
or 'invisible' as a standard value. 
2. Is there any provision to specify PRESENTITY's access rules? (nicely
implemented within msn messenger) 
3. Re Section3.8-> Conflict resolution. Why can't we just accept
'most-recent'(based on Presenceinfo.Status_Duration) status as *the*
valid status value?  
4. What will happen to precedence based system (3) if users are allowed
to enter specific status values ('illegal' as mentioned in Specs) that
may not necessarily fall between 'unavailable' and 'offline' 
5. Re 4 -> Ref. Would be worthwhile to see
http://www.cs.berkeley.edu/~mikechen/im/docs/rfc2779.txt if haven't
referred already.  






From Martin.Wanicki at Australia.Boeing.com  Thu Dec 20 16:27:57 2001
From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin)
Date: Tue Oct 14 08:01:41 2003
Subject: [ticker-dev] Presence specification draft 0.4.1
Message-ID: <21BEC9503B89D111A8F700805FE6A3690AD1FEC2@xch-bne-01.bal.bna.boeing.com>


Hi All,

This is probably my last posting before Christmas, so I'd like to take this
opportunity to wish every one all the best for the season.

The revised presence protocol brings up an issue that may actually improve
the ticker spec, please bear with me while 
I try to explain.

For the purposes of this please consider that the words 'Field' and
'Attribute' to mean the same, its my database background emerging :-)

If missing fields in a notification indicate that a value has not changed it
requires an additional degree of processing in the client
to ensure only existing fields are replaced. Thats fine and fairly trivial
to do, but it leads to something that may be useful in the tickertape
protocol.

In the ticker spec, the "REPLACEMENT" field indicates that the entire
contents of a notification should be replaced, or the original notification
is actually replaced by the new one, whichever way the result is the same
the remaining notification ends up representing whatever notification that
most recently had a replacement id that matched it  To that end it is
conceivable that the replacement function could be extended to perform an
update, updating only existing fields.

So I propose that it may be useful to add an 'UPDATES' field to the
tickertape protocol to not replace a 
notification but to update it with only the changed/supplied fields.

I'm fine to continue without it but I wonder what the ticker community
thinks about this as an idea for a ticker spec extension.

Cheers and all the best

Martin








From Matthew.Phillips at dsto.defence.gov.au  Fri Dec 21 09:51:54 2001
From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew)
Date: Tue Oct 14 08:01:41 2003
Subject: [ticker-dev] Presence specification draft 0.4.1
Message-ID: <8FCECF5E61F0D511946000306E0189F812E417@ednex504.dsto.defence.gov.au>


> 1. Re Section 3.7 -> Status. Do we need something like 
> 'appear offline'
> or 'invisible' as a standard value. 

Not sure what you would use this for - you can always pretend not to be
there by sending an offline status.

> 2. Is there any provision to specify PRESENTITY's access 
> rules? (nicely
> implemented within msn messenger) 

The access rules would be up to the client.  We do have a Requestor field in
Presence-Request that would allow a client to customize what information is
sent.  I think that to do this properly though, you would need to use
security keys.

> 3. Re Section3.8-> Conflict resolution. Why can't we just accept
> 'most-recent'(based on Presenceinfo.Status_Duration) status as *the*
> valid status value?  

Because clients that automatically mark you "unavailable?" after a certain
period of time could override a previous "online" sent by another client.
In general, if you get two replies to a Presence-Request with the same User,
one saying the person is online 10 mins the other saying they are offline 2
mins, I would say you would still err on the side of assuming they are
actually online, even though the offline is more recent.  This is especially
true with clients that automatically go to "unavailable?" after a period of
inactivity, because then an "online" status is a "positive" indication that
they really are there.

> 4. What will happen to precedence based system (3) if users 
> are allowed
> to enter specific status values ('illegal' as mentioned in Specs) that
> may not necessarily fall between 'unavailable' and 'offline' 

A reasonable way to handle illegal statuses is to assume they mean the same
as "unavailable".

> 5. Re 4 -> Ref. Would be worthwhile to see
> http://www.cs.berkeley.edu/~mikechen/im/docs/rfc2779.txt if haven't
> referred already.  

Done.

Cheers,

Matthew.