From ticker-lists at lister.dnsalias.net Fri Mar 19 02:13:36 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Fri Mar 19 02:13:34 2004 Subject: [ticker-dev] Timeout attribute Message-ID: Hi all, It's been a while since we've made any progress on the v3 standard, so I'd like to raise something that's been bugging me for a long time. The choice of minutes for the units of the Timeout attribute is a bit odd. The justification at the Ticker workshop for using minutes rather than seconds (being a standard unit) was that Tickertape has no real need for sub-minute precision, and minutes would do just fine. However, Tickertape notifications often conform to other protocols, and a timeout is a common concept across many protocols. Just because Ticker doesn't feel the _need_ to use anything other than minutes doesn't mean other protocols don't either. We measure time arcanely, but the second is a much more sane unit than the minute. All units smaller than it are decimal (saves you talking in 0.01666ths of a minute), and it's the standard international unit for time. I would like to propose that the Timeout attribute in Tickertape v3 be measured in seconds. David has come up with a plan for avoiding problems in the transition from the current draft implementations (which I'll leave for him to present), and I can't see any reasons not to proceed (other than not being bothered, and I'm certainly bothered :-). Any comments? Ian From arnold at dstc.edu.au Fri Mar 19 05:21:39 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Mar 19 05:21:50 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Fri, 19 Mar 2004 18:13:36 +1000." Message-ID: <200403191121.i2JBLdKc012154@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> It's been a while since we've made any progress on the v3 Ian> standard, so I'd like to raise something that's been bugging me Ian> for a long time. As an aside, I've been slowly working on the general text of the spec, and am basically happy for it to be (finally) published once this issue is resolved. I'll announce the current draft shortly. Ian> The choice of minutes for the units of the Timeout attribute is Ian> a bit odd. The justification at the Ticker workshop for using Ian> minutes rather than seconds (being a standard unit) was that Ian> Tickertape has no real need for sub-minute precision, and Ian> minutes would do just fine. While I don't really recall the detail, the minutes of the session actually say that we agreed on seconds: http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/renaming/index.html (which is neither here nor there, but ... anywway) Ian> However, Tickertape notifications often conform to other Ian> protocols, and a timeout is a common concept across many Ian> protocols. Just because Ticker doesn't feel the _need_ to use Ian> anything other than minutes doesn't mean other protocols don't Ian> either. ie. see the last comment in the notes on the renaming session at the workshop at the URL above. Ian> We measure time arcanely, but the second is a much more sane Ian> unit than the minute. All units smaller than it are decimal Ian> (saves you talking in 0.01666ths of a minute), and it's the Ian> standard international unit for time. Ian> I would like to propose that the Timeout attribute in Ian> Tickertape v3 be measured in seconds. As you might have guessed, Ian and I have spoken (well, tickered) about this, and I agree, for both the reasons above. My reservations were mostly to do with compatibility ... Ian> David has come up with a plan for avoiding problems in the Ian> transition from the current draft implementations (which I'll Ian> leave for him to present), and I can't see any reasons not to Ian> proceed (other than not being bothered, and I'm certainly Ian> bothered :-). So, I recorded the timeouts of all public and Mantara internal ticker traffic today as a small research task. Here's the results: Timeout Number of Messsages ---------------------------- 2 43 5 177 10 6 60 7 1440 6 I also think that it is a greater problem for the scrolling message to disappear too quickly, rather than too slowly. For example, if the timeout was 5 minutes (a popular value), and the message was displayed for only 5 seconds, it's likely that it would disappear before it had even scrolled onto the screen during busy periods. On this basis, and after looking at the UI of some popular tickers, my proposal is this: For a limited transition period, the following rules are applied to timeouts on v3 messages: On reception: If 0 < timeout <= 60, treat the units as minutes Elif timeout == 1440, treat the units as minutes Else, treat the units as seconds On sending: If the user selects 1 minute, set the value to 61 Else, set the value in seconds This will ensure that new clients display messages from old clients for sufficiently long that they're readable. Very old clients (v1) will be unaffected (since the TIMEOUT field is still in minutes), and the current clients will display things for too long (and will require manual deletion). Clients should feel free to interpret the timeout in minutes, if they want, so long as the on-the-wire value is in seconds. Having user-level control to the nearest second is obviously not necessary. Regardless, with new releases of Sticker, eTiks and xtickertape all coming soon, and a new release of aquatik long overdue (did i say that? :-), the transitional period for new clients should be both short, and (I think) bearable in the interim. So ... I think this is a good idea. The more applications we write, the more useful it is to have common semantics for same-named attributes. I realise that some might say "I smell ontologies and I don't like it", but ... I think this is a simple change with some real benefit for future proofing. So ... unless I hear strenuous and compelling objections, I'll update the spec ... :-) d From Matthew.Phillips at dsto.defence.gov.au Sun Mar 21 18:25:46 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Sun Mar 21 18:35:06 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A106B@ednex502.dsto.defence.gov.au> Hi all, at the risk of coming across as overly conservative ;), and while I have occasionally lamented that Timeout does not allow sub-minute values, changing Timeout at this stage seems to add a lot of effort/confusion/complexity for the convenience of allowing conformance with other protocols that may use seconds (does anyone use such a beast?). Not to mention that other "conformant" protocols may require millisecond accuracy. While I'm aware the spec is still technically a draft, it's been "stable" for long enough that two major releases of Sticker are based on it, and it seems that some people go a long time between upgrading their clients (there are still regular Sticker 2.3 users who are quite happy not to move). While I'm aware that drafts are named as such because they may change, I think incompatible changes need to be driven by a severe technical shortcoming found in the original. My proposal would be to add a new field (eg "Timeout-Seconds", "Lifetime", etc) and include "Timeout" rounded up to the nearest minute for backwards compat. Although this is of course bogus, so would adding a temporary guess-what-I-really-meant rule to the next round of clients, one which, presumably, would need to be programmed to turned itself off at a set changeover date, further confusing things. Cheers, Matthew. > -----Original Message----- > From: David Arnold [mailto:arnold@dstc.edu.au] > Sent: Friday, 19 March 2004 9:52 PM > To: ticker-dev@tickertape.org > Subject: Re: [ticker-dev] Timeout attribute > > > -->"Ian" == Ian Lister writes: > > Ian> It's been a while since we've made any progress on the v3 > Ian> standard, so I'd like to raise something that's been bugging me > Ian> for a long time. > > As an aside, I've been slowly working on the general text of the spec, > and am basically happy for it to be (finally) published once this > issue is resolved. I'll announce the current draft shortly. > > Ian> The choice of minutes for the units of the Timeout attribute is > Ian> a bit odd. The justification at the Ticker workshop for using > Ian> minutes rather than seconds (being a standard unit) was that > Ian> Tickertape has no real need for sub-minute precision, and > Ian> minutes would do just fine. > > While I don't really recall the detail, the minutes of the session > actually say that we agreed on seconds: > > > http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/r > enaming/index.html > > (which is neither here nor there, but ... anywway) > > Ian> However, Tickertape notifications often conform to other > Ian> protocols, and a timeout is a common concept across many > Ian> protocols. Just because Ticker doesn't feel the _need_ to use > Ian> anything other than minutes doesn't mean other protocols don't > Ian> either. > > ie. see the last comment in the notes on the renaming session at the > workshop at the URL above. > > Ian> We measure time arcanely, but the second is a much more sane > Ian> unit than the minute. All units smaller than it are decimal > Ian> (saves you talking in 0.01666ths of a minute), and it's the > Ian> standard international unit for time. > > Ian> I would like to propose that the Timeout attribute in > Ian> Tickertape v3 be measured in seconds. > > As you might have guessed, Ian and I have spoken (well, tickered) > about this, and I agree, for both the reasons above. > > My reservations were mostly to do with compatibility ... > > Ian> David has come up with a plan for avoiding problems in the > Ian> transition from the current draft implementations (which I'll > Ian> leave for him to present), and I can't see any reasons not to > Ian> proceed (other than not being bothered, and I'm certainly > Ian> bothered :-). > > So, I recorded the timeouts of all public and Mantara internal ticker > traffic today as a small research task. Here's the results: > > Timeout Number of Messsages > ---------------------------- > 2 43 > 5 177 > 10 6 > 60 7 > 1440 6 > > I also think that it is a greater problem for the scrolling message to > disappear too quickly, rather than too slowly. For example, if the > timeout was 5 minutes (a popular value), and the message was displayed > for only 5 seconds, it's likely that it would disappear before it had > even scrolled onto the screen during busy periods. > > On this basis, and after looking at the UI of some popular tickers, my > proposal is this: > > For a limited transition period, the following rules are applied to > timeouts on v3 messages: > > On reception: > If 0 < timeout <= 60, treat the units as minutes > Elif timeout == 1440, treat the units as minutes > Else, treat the units as seconds > > On sending: > If the user selects 1 minute, set the value to 61 > Else, set the value in seconds > > This will ensure that new clients display messages from old clients > for sufficiently long that they're readable. Very old clients (v1) > will be unaffected (since the TIMEOUT field is still in minutes), and > the current clients will display things for too long (and will require > manual deletion). > > Clients should feel free to interpret the timeout in minutes, if they > want, so long as the on-the-wire value is in seconds. Having > user-level control to the nearest second is obviously not necessary. > > Regardless, with new releases of Sticker, eTiks and xtickertape all > coming soon, and a new release of aquatik long overdue (did i say > that? :-), the transitional period for new clients should be both > short, and (I think) bearable in the interim. > > > So ... I think this is a good idea. The more applications we write, > the more useful it is to have common semantics for same-named > attributes. I realise that some might say "I smell ontologies and I > don't like it", but ... I think this is a simple change with some real > benefit for future proofing. > > > So ... unless I hear strenuous and compelling objections, I'll update > the spec ... :-) > > > > > > > d > > > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From ticker-lists at lister.dnsalias.net Sun Mar 21 20:11:25 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Sun Mar 21 20:11:25 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: <6949B1A32630D811B8CB00306E013ADE0A106B@ednex502.dsto.defence.gov.au> Message-ID: On Mon, 22 Mar 2004, Phillips, Matthew wrote: >at the risk of coming across as overly conservative ;), and while I have >occasionally lamented that Timeout does not allow sub-minute values, >changing Timeout at this stage seems to add a lot of >effort/confusion/complexity for the convenience of allowing conformance >with other protocols that may use seconds (does anyone use such a >beast?). Not to mention that other "conformant" protocols may require >millisecond accuracy. That's OK, Elvin supports floating point numbers too. And working in .001's of a second is a lot more sane than working in 0.000016666's of a minute. The initial list of standard attributes I put forward around 18 months ago describes Timeout as being a number, which doesn't preclude the use of floating point numbers where appropriate. >While I'm aware the spec is still technically a draft, it's been "stable" >for long enough that two major releases of Sticker are based on it, and >it seems that some people go a long time between upgrading their clients >(there are still regular Sticker 2.3 users who are quite happy not to >move). While I'm aware that drafts are named as such because they may >change, I think incompatible changes need to be driven by a severe >technical shortcoming found in the original. The change has a pretty compatible migration path. It's not like making the change breaks interoperability between old draft clients and new draft clients. If you're concerned about reducing the impact of the change even more, David's original proposal (not sent to the list) observed that the deployed draft clients use only a small set of discrete timeout values, so clients interested in minimising impact could interpret those values as being in minutes and ensure they don't send those values. For example, if you receive a notification with a Timeout of 5 (the most commonly used timeout) you can interpret that as being 5 minutes, and if you allow the user to send a notification with a timeout of 5 seconds (which you probably wouldn't) you'd actually send it as 6. Alternatively you can just use the v1 attribute if it exists to be certain. >My proposal would be to add a new field (eg "Timeout-Seconds", >"Lifetime", etc) and include "Timeout" rounded up to the nearest minute >for backwards compat. Although this is of course bogus, so would adding a >temporary guess-what-I-really-meant rule to the next round of clients, Fortunately the bogosity in adding the temporary compatibility rule is only temporary, whereas putting the bogosity into the final standard would be rather more permanent. >one which, presumably, would need to be programmed to turned itself off >at a set changeover date, further confusing things. That wouldn't be necessary. It is correct that the draft compatibility behaviour would only be necessary for a transition period, but after that period you can just remove the behaviour from future client releases whenever you get around to it. It won't hurt to keep it there longer if you don't bother removing it, and it won't hurt if people continue to use older releases with the compatibility code still in it. Ian From Matthew.Phillips at dsto.defence.gov.au Mon Mar 22 00:08:49 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Mon Mar 22 00:14:58 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A106F@ednex502.dsto.defence.gov.au> > On Mon, 22 Mar 2004, Phillips, Matthew wrote: > >at the risk of coming across as overly conservative ;), and > while I have > >occasionally lamented that Timeout does not allow sub-minute values, > >changing Timeout at this stage seems to add a lot of > >effort/confusion/complexity for the convenience of allowing > conformance > >with other protocols that may use seconds (does anyone use such a > >beast?). Not to mention that other "conformant" protocols may require > >millisecond accuracy. > > That's OK, Elvin supports floating point numbers too. And working in > .001's of a second is a lot more sane than working in > 0.000016666's of a > minute. Well, except that floating point doesn't guarantee to exactly represent numbers like 0.001... > >move). While I'm aware that drafts are named as such because they may > >change, I think incompatible changes need to be driven by a severe > >technical shortcoming found in the original. > > The change has a pretty compatible migration path. It's not > like making > the change breaks interoperability between old draft clients > and new draft > clients. No, but it does mean that interpreting the actual meaning of Timeout may require consulting the User-Agent field and a lookup table ;) Yes, I guess you could avoid the magic numbers of 5 etc if you really mean seconds, but we haven't addressed how old clients seeing, for example, "Timeout: 30" are supposed to know that this means 30 seconds not 30 minutes. > >My proposal would be to add a new field (eg "Timeout-Seconds", > >"Lifetime", etc) and include "Timeout" rounded up to the > nearest minute > >for backwards compat. Although this is of course bogus, so > would adding a > >temporary guess-what-I-really-meant rule to the next round > of clients, > > Fortunately the bogosity in adding the temporary compatibility rule is > only temporary, whereas putting the bogosity into the final > standard would > be rather more permanent. Temporary, but long-lasting. Like I've said, clients tend to hang around, so old hacks tend to stick around too. Witness the fact that we still haven't switched to ticker 3.0 and currently have 3 different formats. Adding this extra rule makes 4: ticker 3.0draft1 and 3.0final. I can see this being hugely confusing for little gain - I really think we missed the window of opportunity to do this. We don't even seem to have an actual application for the new timeout field. And although it does appear that several clients will have releases soon, speaking for myself I'm working towards a stable version with features required for Defence HQ use, so a disruptive change like this is unlikely to make the cut. Cheers, Matthew. From arnold at dstc.edu.au Mon Mar 22 03:01:53 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Mar 22 03:02:05 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Mon, 22 Mar 2004 10:55:46 +1030." <6949B1A32630D811B8CB00306E013ADE0A106B@ednex502.dsto.defence.gov.au> Message-ID: <200403220901.i2M91rKc006280@piglet.dstc.edu.au> -->"Matt" == Phillips, Matthew writes: Matt> While I'm aware that drafts are named as such because they may Matt> change, I think incompatible changes need to be driven by a Matt> severe technical shortcoming found in the original. In general, changing drafts is good. It's what they're for. Changing a standard is another thing. We're in a middle-ground here in that the draft has been static for a long time, and so it has come to be seen as a "standard" despite its flaws. Matt> My proposal would be to add a new field (eg "Timeout-Seconds", Matt> "Lifetime", etc) and include "Timeout" rounded up to the Matt> nearest minute for backwards compat. If we were looking at changing a standard, that's what we'd have to do (or, please no, Timeout-2 or something). My goal here is to get the best possible standard. I know there's some short-term pain involved, but in a few years that'll be forgotten, and we'll still be reaping the benefits of a standard name for timing out information. d From arnold at dstc.edu.au Mon Mar 22 03:16:03 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Mar 22 03:16:12 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Mon, 22 Mar 2004 12:11:25 +1000." Message-ID: <200403220916.i2M9G3Kc007191@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> Alternatively you can just use the v1 attribute if it exists to Ian> be certain. In fact, this is the best approach for messages with v1 data present, which slightly modifies my proposed alorithm for reception: if (msg.containsKey("TIMEOUT")) { timeout = msg.getInt("TIMEOUT") * 60; } else if (msg.containsKey("Timeout")) { msgTimeout = msg.getInt("Timeout"); if ((msgTimeout > 0 && msgTimeout <= 60) || msgTimeout == 1440) { timeout = msgTimeout * 60; } else { timeout = msgTimeout; } } transmission is the same: v1Timeout = uiTimeout; if (uiTimeout == 1) { v3Timeout = 61; } else { v3Timeout = uiTImeout * 60; } or something like that :-) d From arnold at dstc.edu.au Mon Mar 22 03:38:03 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Mar 22 03:38:11 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Mon, 22 Mar 2004 16:38:49 +1030." <6949B1A32630D811B8CB00306E013ADE0A106F@ednex502.dsto.defence.gov.au> Message-ID: <200403220938.i2M9c3Kc008553@piglet.dstc.edu.au> -->"Matt" == Phillips, Matthew writes: >> The change has a pretty compatible migration path. It's not like >> making the change breaks interoperability between old draft >> clients and new draft clients. Matt> No, but it does mean that interpreting the actual meaning of Matt> Timeout may require consulting the User-Agent field and a Matt> lookup table ;) Yes, I guess you could avoid the magic numbers Matt> of 5 etc if you really mean seconds, but we haven't addressed Matt> how old clients seeing, for example, "Timeout: 30" are Matt> supposed to know that this means 30 seconds not 30 minutes. My assumption here is two-fold: a) The timeout is the least important piece of information in the message, and if it's misinterpreted or even totally ignored, that's both legal (from a specification point of view) and reasonably acceptable from a user's point of view. b) The current user-base is both small and technically literate compared to the userbase we'd hope for in the future. This means that it's fairly easy to say now that "you have to upgrade to make this work right" compared to saying that in the future when the joint chiefs are using it :-) So I was proposing a very simple transition (and certainly not anything as elaborate as looking at User-Agent values). The fact that messages to various public channels used timeouts ranging from 1 to 60 minutes for postings indicated to me that people either didn't care about the expiry time, or overrode the extreme values in their client anyway. Matt> Temporary, but long-lasting. Like I've said, clients tend to Matt> hang around, so old hacks tend to stick around too. Witness Matt> the fact that we still haven't switched to ticker 3.0 and Matt> currently have 3 different formats. Adding this extra rule Matt> makes 4: ticker 3.0draft1 and 3.0final. I think a large part of the reason for the prolonged life of v1 is that v3 is not finalised. The reason it's not finalised is that it has some problems. So I'm trying to remove those problems, so it can be finalized, so we can then get rid of v1 and draft-based v3 implementations. Matt> I can see this being hugely confusing for little gain - I Matt> really think we missed the window of opportunity to do Matt> this. I am sympathetic to your position -- you've got a good user base, a stable code base, and making changes is painful. I can only say that it's my feeling that this is a minor issue in the greater scheme of tickertape, and getting it closer to right is worth the minor pain. Matt> We don't even seem to have an actual application for the new Matt> timeout field. There are other message formats that use timeouts, and could benefit from a common definition. However, that's not really the point -- TIMEOUT also worked just fine, but we changed it to Timeout because we thought that was better, and worth the pain. Matt> And although it does appear that several clients will have Matt> releases soon, speaking for myself I'm working towards a Matt> stable version with features required for Defence HQ use, so a Matt> disruptive change like this is unlikely to make the cut. I'd hoped it wasn't majorly disruptive -- users, especially those at Defence HQ who will all be using the new client, are unlikely to even be aware that this has changed. I reckon the long-term benefits outweigh the cost, but ... d From Matthew.Phillips at dsto.defence.gov.au Mon Mar 22 19:09:06 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Mon Mar 22 19:15:16 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A1078@ednex502.dsto.defence.gov.au> Well, David's well-considered arguments and a re-reading of the workaround proposal (plus a really nice cup of coffee) have gone a long way towards convincing me. Although whenever I think of how I'm going to explain this translation requirement to others, I still cringe. Several prople writing producers have already been amazed that there are three formats for doing essentially the same thing. But I take the point that Timeout isn't very important anyway. How about this as a way to ease the transition: 3.0final messages using the new Timeout get a "org.tickertape.message: 3001" tag, messages with "org.tickertape.message: 3000" are 3.0draft1 and messages with no version field are considered to be 3.0final. This allows next-release clients to detect what the units of Timeout are from older clients. It doesn't remove the need to translate on sending, but has the nice effect that clients looking for org.tickertape.message == 3000 as a marker of v3 message content will read the v1 content instead and not see the 60-fold timeout increase. Not sure about other clients, but this works well for Sticker, and at least won't make it any worse for others. With this scheme, the 50+ Sticker's that I see currently running will ignore the new Timeout and won't suddenly get spammed with "immortal" ticker messages between the point that we start testing the new format and they upgrade to 3.1. Cheers, Matt. > -----Original Message----- > From: David Arnold [mailto:arnold@dstc.edu.au] > Sent: Monday, 22 March 2004 8:08 PM > To: ticker-dev@tickertape.org > Subject: Re: [ticker-dev] Timeout attribute > > > -->"Matt" == Phillips, Matthew > writes: > > >> The change has a pretty compatible migration path. It's not like > >> making the change breaks interoperability between old draft > >> clients and new draft clients. > > Matt> No, but it does mean that interpreting the actual meaning of > Matt> Timeout may require consulting the User-Agent field and a > Matt> lookup table ;) Yes, I guess you could avoid the magic numbers > Matt> of 5 etc if you really mean seconds, but we haven't addressed > Matt> how old clients seeing, for example, "Timeout: 30" are > Matt> supposed to know that this means 30 seconds not 30 minutes. > > My assumption here is two-fold: > > a) The timeout is the least important piece of information in the > message, and if it's misinterpreted or even totally ignored, that's > both legal (from a specification point of view) and reasonably > acceptable from a user's point of view. > > b) The current user-base is both small and technically literate > compared to the userbase we'd hope for in the future. This means > that it's fairly easy to say now that "you have to upgrade to make > this work right" compared to saying that in the future when the > joint chiefs are using it :-) > > So I was proposing a very simple transition (and certainly not > anything as elaborate as looking at User-Agent values). > > The fact that messages to various public channels used timeouts > ranging from 1 to 60 minutes for postings indicated to me that people > either didn't care about the expiry time, or overrode the extreme > values in their client anyway. > > Matt> Temporary, but long-lasting. Like I've said, clients tend to > Matt> hang around, so old hacks tend to stick around too. Witness > Matt> the fact that we still haven't switched to ticker 3.0 and > Matt> currently have 3 different formats. Adding this extra rule > Matt> makes 4: ticker 3.0draft1 and 3.0final. > > I think a large part of the reason for the prolonged life of v1 is > that v3 is not finalised. The reason it's not finalised is that it > has some problems. So I'm trying to remove those problems, so it can > be finalized, so we can then get rid of v1 and draft-based v3 > implementations. > > > Matt> I can see this being hugely confusing for little gain - I > Matt> really think we missed the window of opportunity to do > Matt> this. > > I am sympathetic to your position -- you've got a good user base, a > stable code base, and making changes is painful. > > I can only say that it's my feeling that this is a minor issue in the > greater scheme of tickertape, and getting it closer to right is worth > the minor pain. > > Matt> We don't even seem to have an actual application for the new > Matt> timeout field. > > There are other message formats that use timeouts, and could benefit > from a common definition. > > However, that's not really the point -- TIMEOUT also worked just fine, > but we changed it to Timeout because we thought that was better, and > worth the pain. > > Matt> And although it does appear that several clients will have > Matt> releases soon, speaking for myself I'm working towards a > Matt> stable version with features required for Defence HQ use, so a > Matt> disruptive change like this is unlikely to make the cut. > > I'd hoped it wasn't majorly disruptive -- users, especially those at > Defence HQ who will all be using the new client, are unlikely to even > be aware that this has changed. > > I reckon the long-term benefits outweigh the cost, but ... > > > > > d > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From ticker-lists at lister.dnsalias.net Wed Mar 24 01:16:55 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Wed Mar 24 01:16:53 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: <6949B1A32630D811B8CB00306E013ADE0A1078@ednex502.dsto.defence.gov.au> Message-ID: On Tue, 23 Mar 2004, Phillips, Matthew wrote: >How about this as a way to ease the transition: 3.0final messages using >the new Timeout get a "org.tickertape.message: 3001" tag, messages with >"org.tickertape.message: 3000" are 3.0draft1 and messages with no version >field are considered to be 3.0final. That doesn't seem too unreasonable. I was wondering why we called it org.tickertape.message instead of message.tickertape.org? I remember there was an minor argument in favour of the latter because it allowed string comparisons called in the case of hash collisions to complete slightly quicker, but I can't recall any arguments in favour of the former. The minutes that David posted the other day (http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/renaming/index.html) also refer to a tickertape.elvin.org attribute. Anyway, this might be a possible way out if we wanted to change the name of that attribute at the same time as changing Timeout... :-) Perhaps we should take this as a lesson that in future we shouldn't have clients implemementing a draft claim to implement the final standard? Although with a purely numeric version that might get a bit ugly. Ian From arnold at dstc.edu.au Thu Mar 25 02:39:42 2004 From: arnold at dstc.edu.au (David Arnold) Date: Thu Mar 25 02:39:55 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Wed, 24 Mar 2004 17:16:55 +1000." Message-ID: <200403250839.i2P8dhTr003121@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: >> How about this as a way to ease the transition: 3.0final messages >> using the new Timeout get a "org.tickertape.message: 3001" tag, >> messages with "org.tickertape.message: 3000" are 3.0draft1 and >> messages with no version field are considered to be 3.0final. Ian> That doesn't seem too unreasonable. I'd be happy with that too. Ian> I was wondering why we called it org.tickertape.message instead Ian> of message.tickertape.org? I remember there was an minor Ian> argument in favour of the latter because it allowed string Ian> comparisons called in the case of hash collisions to complete Ian> slightly quicker, but I can't recall any arguments in favour of Ian> the former. The minutes that David posted the other day Ian> (http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/renaming/index.html) Ian> also refer to a tickertape.elvin.org attribute. Anyway, this Ian> might be a possible way out if we wanted to change the name of Ian> that attribute at the same time as changing Timeout... :-) eek! Ok. Since tickertape.org (the collective wisdom and presence implied by this mailing list) "owns" the domain name tickertape.org, I think it makes sense to use tickertape.org as the root of the protocol identifier. Whether the namespace should run general->specific (JANET, Java, etc), or specific->general (DNS), I don't really know. Making that decision on the basis of a very minor optimisation in one implementation of the Elvin client access protocol seems a little silly to me :-) If we could change the field name, and consequently keep the version number at 3000, that might be a compromise I'd be interested in, although it seems like some additional complexity in the apps? Ian> Perhaps we should take this as a lesson that in future we Ian> shouldn't have clients implemementing a draft claim to Ian> implement the final standard? Although with a purely numeric Ian> version that might get a bit ugly. I think the biggest lesson is "don't let draft protocols drag out for 3 years" :-/ But, more concretely, i think you're right -- having draft protocols using the final spec version number is asking for trouble. I can't think of a simple solution though .. 2999 seems a bit broken. Why do we have 1000 micro versions again? Maybe 3.0final should be 3010 ? d From Matthew.Phillips at dsto.defence.gov.au Fri Mar 26 02:06:56 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Fri Mar 26 02:10:27 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A1091@ednex502.dsto.defence.gov.au> [David] " If we could change the field name, and consequently keep the version number at 3000, that might be a compromise I'd be interested in, although it seems like some additional complexity in the apps? Ian> Perhaps we should take this as a lesson that in future we Ian> shouldn't have clients implemementing a draft claim to Ian> implement the final standard? Although with a purely numeric Ian> version that might get a bit ugly. I think the biggest lesson is "don't let draft protocols drag out for 3 years" :-/ But, more concretely, i think you're right -- having draft protocols using the final spec version number is asking for trouble. I can't think of a simple solution though .. 2999 seems a bit broken. Why do we have 1000 micro versions again? Maybe 3.0final should be 3010 ? " It's a bit arbitrary either way: there doesn't seem much reason to prefer 3010 over 3100 for example. If the original idea was that major numbers => complete incompatibility =>, minor => backwards compatibility, then technically this change should make the version 4000 - but I don't even want to think about going there :/ I'm happy with any combination, but 3001 seems the "least illogical" ;) Matt. From david at mantara.com Mon Apr 5 21:29:29 2004 From: david at mantara.com (David Arnold) Date: Tue Apr 6 02:31:53 2004 Subject: [ticker-dev] metamail and attachments Message-ID: after some experiementation this morning, it appears that there is a bug in metamail-2.7, which is the current (since about 1993 or something ridiculous) release of the program used on many Unix platforms for interpreting MIME attachments. metamail fails to detect the end of the RFC-2822 headers when they are properly terminated with a CRLF+CRLF sequence (ie. a blank line). a LF+LF sequence *does* work, suggesting to me that it incorrectly reads a CRLF as a non-empty line (containing a single CR). since this package is both reasonably ubiquitous on Unix (although gradually being replaced now by GNOME/KDE/etc) and unmaintained, an upstream bugfix is unlikely to happen. unix clients that use metamail to handle attachments should be aware of this problem, and modify the attachment content appropriately before spawning metamail. fyi, d From Matthew.Phillips at dsto.defence.gov.au Wed Apr 7 02:17:16 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Wed Apr 7 02:23:05 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10BC@ednex502.dsto.defence.gov.au> So, to get some closure here, how about I post my +1 for the "org.tickertape.message: 3001" proposal? Any dissenters? Matthew. > -----Original Message----- > From: Phillips, Matthew [mailto:Matthew.Phillips@dsto.defence.gov.au] > Sent: Friday, 26 March 2004 6:37 PM > To: ticker-dev@tickertape.org > Subject: RE: [ticker-dev] Timeout attribute > > > [David] > " > If we could change the field name, and consequently keep the version > number at 3000, that might be a compromise I'd be interested in, > although it seems like some additional complexity in the apps? > > Ian> Perhaps we should take this as a lesson that in future we > Ian> shouldn't have clients implemementing a draft claim to > Ian> implement the final standard? Although with a purely numeric > Ian> version that might get a bit ugly. > > I think the biggest lesson is "don't let draft protocols drag out for > 3 years" :-/ > > But, more concretely, i think you're right -- having draft protocols > using the final spec version number is asking for trouble. > > I can't think of a simple solution though .. 2999 seems a bit broken. > Why do we have 1000 micro versions again? > > Maybe 3.0final should be 3010 ? > " > > It's a bit arbitrary either way: there doesn't seem much > reason to prefer 3010 over 3100 for example. If the original > idea was that major numbers => complete incompatibility =>, > minor => backwards compatibility, then technically this > change should make the version 4000 - but I don't even want > to think about going there :/ I'm happy with any combination, > but 3001 seems the "least illogical" ;) > > Matt. > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From david at mantara.com Sun Apr 11 21:08:11 2004 From: david at mantara.com (David Arnold) Date: Sun Apr 11 21:30:58 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Wed, 07 Apr 2004 16:47:16 +0930." <6949B1A32630D811B8CB00306E013ADE0A10BC@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> So, to get some closure here, how about I post my +1 for Matthew> the "org.tickertape.message: 3001" proposal? Any Matthew> dissenters? I'm happy with this. I've attached the current draft of the specification, updated to reflect what I believe is the consensus position on all attributes. This would be a good time for everyone to read it, carefully, cover to cover, and object to anything you find objectionable :-) d -------------- next part -------------- INTERNET-DRAFT D. Arnold, Editor tickertape.org Expires: 12 Oct 2004 12 Apr 2004 Tickertape Chat Protocol version 3 draft-arnold-ticker-chat-v3-00.txt 1. Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 2. Abstract This document describes an Elvin message format as used by the Tickertape family of applications. It supports group-oriented, inter-person and machine-to-person instant messaging and provides a simple, consistent interface for presentation of a variety of interactive- time data. This specification is derived from a series of earlier informal message format conventions, as documented in Appendix B. 3. Terminology This document refers to Elvin clients, producers, and consumers; client libraries and routers. An Elvin router is a daemon process that runs on a single machine. It acts as a distribution mechanism for Elvin Arnold Expires in 6 months [Page 1] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 messages. A client is a program that uses an Elvin router, via a client library for a particular programming language. A client library implements the Elvin proto- cols and manages one or more connections to Elvin routers. The sender of an Elvin message is often referred to as a `producer', and receivers as `consumers'. A single client may perform either or both roles. Further details of the Elvin protocol, its entities and their roles is available in [ELVIN]. 3.1. Notation Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be inter- preted as described in [RFC2119]. 4. Tickertape The Tickertape family of applications provide person-to- person and software-to-person instant messaging. As the name suggests, the original user interface consisted of a scrolling line of text, showing a series of messages. Alternative styles of presentation have since become available, but the name Tickertape has remained descrip- tive of the whole family of applications which variously support the creation, reception and often both, of instant messages. Producers support composition of messages and sending them to a specified group. A particular message can be sent independently, or as a reply to a preceding message. Consumers subscribe to messages, often by group name, but alternatively by some other combination of attributes of the message. Interactive clients normally display a subset of the received messages' attributes, and facilitate composition of initial or reply messages. From its earliest prototypes, the facility has been used by software to interact with human users. Both unidirec- tional messages, such as hardware alerts, and automated responders (or bots) have long formed a part of the Tick- ertape culture. What distinguishes Tickertape from other messaging appli- cations and protocols such as [xy]talk, IRC, Jabber/XMPP, Arnold Expires in 6 months [Page 2] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 and the various proprietary instant messaging systems, is its ability to extend beyond a point-to-point, group or channel-based communications using the content-based routing abilities of the underlying Elvin transport. 4.1. Groups The basic structural element of the Tickertape communica- tions space is the concept of groups. A group is defined by its name: a string that is specified by the message producer, and this provides a basic point of context for rendezvous with consumers. The group name performs the role of a channel or forum, for selecting messages with related content. Most Tickertape clients maintain a persistent list of group names which are simply selectable during message composition. Many clients also allow group names to be entered directly, allowing ad hoc group creation. Group names need not be predefined, nor do they have any required structure. Collisions between same-named groups from previously unconnected administrative domains are both possible and likely. Such collisions can be desir- able: the two communities might share a common interest or purpose. Where the collision is not productive, the normal response is to restrict the distribution of mes- sages in that group to within the administrative domain. 4.2. Sender Identity Tickertape messages include the identity of the sending entity as a string value. While there are no constraints on the values that may be used for this attribute, common usage has evolved several conventions for the identity string: Most clients default to using an identity string of the form user@domain thus providing a simple distinction between users, derived from the implicit uniqueness of their login name in combination with their machine's domain name. The obvious similarity with email addresses is not unin- tentional. Rather than requiring a new naming scheme, use of an email address reduces the likelyhood of colli- sions, and takes advantage of users' familiarity with this form of identifier. Arnold Expires in 6 months [Page 3] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 However, a second convention has evolved that uses the form user@location This usage, while similar in appearance, is quite dis- tinct. One typical value for the location component is the user's company name, which provides some level of uniqueness, but is not as robust as a complete domain name. However, a second common usage has the location as "home", which provides very little distinction between users. These issues have not been addressed in the protocol specification because no clear consensus has arisen that it is a problem. Collision between identifiers does occur, but it is resolved by social, rather than proto- col, mechanisms. 5. Elvin Tickertape uses Elvin as its underlying communications layer. Elvin provides a one-to-any, publish/subscribe transport with atomic, consistent per-source ordering, best-effort delivery semantics. Defined mappings exist for TCP, UDP and other bearer protocols. Elvin messages are structured, using a flat name space of basic data types, including Unicode strings. Messages are transmitted to an Elvin router, where they are com- pared against the registered subscriptions. A copy of the message is delivered to the owner of each matching subscription and to other connected routers. Subscriptions are expressed as predicates in a simple, C- like syntax. In addition to the usual comparison and arithmetic operators, functions are provided to test the existence and type of values, to perform case folding and normalisation, and for regular expression and glob-style wildcard matching. Further details of the protocol and subscription language are available in [ELVIN]. 6. Message Specification This document specifies the basic Tickertape 'chat' mes- sage format. Several other message formats are fre- quently implemented by a Tickertape client, for example that for presence notifications [PRESENCE]. Arnold Expires in 6 months [Page 4] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 A Tickertape chat message has three fundamental proper- ties: the sending entity's name, a specified target group, and a textual message body. These basic proper- ties are then augmented to allow message ageing, threaded conversations, attachments and other features. 6.1. Base Attributes The base attributes MUST be present in all Tickertape chat messages. Name Type Description ----------------------------------------------------------------- Group string The name of the group to which this mes- sage is sent. From string The name of the sender of the message. Message string Text to be displayed in the scroller (or similar user interface location). Message-Id string A globally unique identifier for this mes- sage. The use of some combination of host name, process identifier and time of day (for example a GUID or UUID), hashed (using SHA.1, MD5, etc) to ensure anonymity is RECOMMENDED. ----------------------------------------------------------------- Tickertape client applications typically provide the ability to subscribe to messages using the 'Group' name, and frequently arbitrary subscriptions over the 'From', 'Message' and other attributes. String-valued Elvin attributes use the UTF-8 [RFC2279] Unicode [UNICODE] character encoding. In some cases, a single character may have multiple representations in Unicode. As an example, a base character combined with an accent can sometimes have a single code for the combi- nation, or use multiple codes to represent the base char- acter plus a combining accent. The Elvin subscription language provides operations to transform strings to canonical representations to ensure that strings using different representations of the same characters are correctly matched. Implementors of Tick- ertape protocol clients SHOULD use these features to ensure that user expectations are fulfilled. Arnold Expires in 6 months [Page 5] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 6.2. Replies and Intra-group Threads When sending a message as a reply to a previously received message, implementations MUST identify that mes- sage as a means of supporting presentation of conversa- tions in order. Name Type Description --------------------------------------------------------------- In-Reply-To string The Message-Id of a previous message to which this is a reply. --------------------------------------------------------------- 6.3. Private or Extra-group Threads It is possible to send messages directed to a group to which the sender is not subscribed. This is commonly used when the sender wants to initiate a convesation with the user(s) of the channel, but does not want to see traffic on that channel from other conversations. The sender includes a Thread-Id attribute in the initial message, and temporarily subscribes to all messages with a matching Thread-Id value. Responding clients copy the received Thread-Id value into any replies made to that message, and thus the responses are visible to the original poster. A client responding to a message containing a Thread-Id attribute MUST include a Thread-Id attribute with that value in its response. Name Type Description ---------------------------------------------------------------- Thread-Id string When sending a message to a group to which the sender is not subscribed but wishes to see any replies, this field should be set (and the sender's user agent should alter its subscription so as to receive any mes- sages with this Thread-Id value). This value must be globally unique. See Message-Id for recommendations. ---------------------------------------------------------------- 6.4. Optional Attributes The following attributes MAY be included, at the discre- tion of the application writer or controlling user. Arnold Expires in 6 months [Page 6] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 6.4.1. Protocol Version Elvin messages are sufficiently self-descriptive that applications can be written to cater for missing or addi- tional attributes to those expected. It is therefore not necessary for robust communication that the protocol ver- sion in use be formally specified. However, if a producer wishes to indicate that it sup- ports this specification, it MAY do so using the follow- ing attribute. Note that this information is purely informative, and an application MUST NOT fail because of a discrepancy between the version indicated with this attribute, and the format of the message. Name Type Description ------------------------------------------------------------------ org.tickertape.message int32 The version of this specifica- tion implemented by the message. For this revision, the value MUST be an Elvin int32, with a value of 3001. ------------------------------------------------------------------ 6.4.2. Message Validity For Tickertape consumer applications, it is sometimes useful to have an indication of the valid or useful lifespan of a message. This attribute allows the pro- ducer to suggest a time period after which the message might be removed from the display or otherwise depriori- tised. A positive value suggests that the message be removed from display after that many seconds. Clients MAY inter- pret this value liberally; a resolution in the order of minutes is normally adequate. Special interpretation SHOULD be applied for a value of zero, indicating that the message be shown briefly; and negative values, suggesting that it not be shown at all, but displayed only in logs or historical views. Name Type Description ------------------------------------------------------------- Timeout int32 Suggested lifetime of the message, in sec- onds. ------------------------------------------------------------- Arnold Expires in 6 months [Page 7] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 6.4.3. User Agent Identification User agents (clients) MAY identify themselves as the sending agent of Tickertape messages. If they do, this attribute SHOULD be used for that purpose. Name Type Description ------------------------------------------------------------- User-Agent string The name and version of the user agent (program) generating this message. ------------------------------------------------------------- 6.4.4. Archiving One common class of Tickertape consumer programs makes a permanent record of message traffic, usually on a per- channel basis. Producers can optionally allow the user to indicate that a message should not be archived in this manner. Archiver clients SHOULD implement support for this attribute, and SHOULD NOT store messages for which it exists, and has a non-zero value. Name Type Description -------------------------------------------------------------- No-Archive int32 The sender of a message can request that it not be archived by setting this attribute with a non-zero value. -------------------------------------------------------------- 6.4.5. Distribution This attribute is intended for interpretation by forward- ing filters at administrative boundaries and describes restrictions on the distribution of this message. No constraints are set on the value of this field, but examples might include "local", the company name, "unclassified", etc. Note that no global interpretation is placed on the val- ues of this field. Its meaning is defined within an administrative domain, to be interpreted at its adminis- trative boundaries. Multiple levels of such interpreta- tion are possible. Future standardisation of the semantics of this attribute is likely. Arnold Expires in 6 months [Page 8] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 Name Type Description ------------------------------------------------------------------- Distribution string A value, intended for interpretation by forwarding filters at administrative boundaries, describing restrictions on the distribution of this message. No constraints are set on the value of this field, except that it SHOULD have a string value. ------------------------------------------------------------------- 6.4.6. Attachments In addition to the simple textual message content, it is often useful to attach URLs, file references, sounds, email addresses or other content to a Tickertape message. This attribute provides a means to attach additional con- tent encoded using the MIME standards [RFC2045-RFC2049]. Note that this field is an Elvin string type, and thus its value must be legitimate UTF-8. The MIME specifica- tion provides various options for encoding data which is not compatible with its containing protocol (ie. base64 encoding, see [RFC1421] section 4.3.2.4). One of these mechanisms MUST be used to ensure that binary content is safely transported. In choosing to use a string type for this attribute, our major motivation was to enable subscription to the attached information (where it is in un-encoded form). This includes things like the MIME content types, etc. Content that is valid UTF-8 SHOULD NOT be additionally encoded so as to facilitate subscription to messages by their attached content. The most common form of attachment is a URL. URLs SHOULD use the text/uri-list MIME type. Multiple attached objects can be encoded using the multipart/mixed MIME type. Name Type Description ---------------------------------------------------------------- Attachment string A MIME-encoded addition to the message. Note that this value must be a legitimate UTF-8 Unicode string, and consequently, binary values must be encoded using, for example, base 64 encoding. ---------------------------------------------------------------- Arnold Expires in 6 months [Page 9] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 6.4.7. Updating Existing Messages In a scrolling user interface, it can be useful to have messages that are constantly visible, but whose content is updated over time. An example of such a message might be the current score in a sporting event. A producer application that wishes to enable such replacement MAY include this field in sent messages. The value MUST be globally unique unless the message is intended to replace a previous message; see Message-Id for recommended practice in generating unique identi- fiers. A consumer application that wishes to allow update of currently displayed messages should compare the value of an arriving message's Replaces field with those of exist- ing messages. The attributes of the arriving message should replace those of any previous message(s) with matching Replaces value(s). If no currently displayed message's Replaces field matches this value, the arriving message is presented as usual. Name Type Description -------------------------------------------------------------- Replaces string An identifier, either unique to this mes- sage, or matching a previous message's Replaces value. -------------------------------------------------------------- 7. Access Control Elvin supports the use of keys to control visibility of both messages and subscriptions [ELVIN]. This specifica- tion does not mandate the use of a particular key scheme, or a method of applying the general Elvin access control facilities to Tickertape Chat messages. It is likely that a companion document, or a future revi- sion of this document, will describe such a method. 8. Security Considerations 8.1. Access Control Unless a Tickertape client uses a proprietry method to constrain the visibility of Tickertape messages using Elvin access control, all messages and subscriptions should be considered exposed to any user with access to Arnold Expires in 6 months [Page 10] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 the supporting Elvin router infrastructure. 8.2. Sender Identity The presented user identity, obtained from the From attribute of the message, can be either empty or mislead- ing. 8.3. Attachments The optional use of the 'Attachment' attribute to deliver a MIME-encoded object allows arbitrary data to be deliv- ered to the receiver's machine. This data can be inter- preted by the client program, and this interpretation could involve the execution of arbitrary code. Client application developers and end-users should ensure that the interpretation of MIME data occurs within appro- priate safeguards. Some user agents also provide a facility to automatically invoke the interpretation of MIME attachments. This practice introduces an additional risk, precluding a man- ual vetting of the data before interpretation. 8.4. Message Replacement The use of the 'Replaces' attribute to update a previous message's content can be abused by an attacker to rewrite any replaceable message. 8.5. Denial of Service It is possible to attack either an individual Tickertape client, or the Elvin routing network, by sending a large number of Tickertape messages. This type of attack could impact local network bandwidth, Elvin router latency and CPU usage, and Tickertape client host CPU usage. The combination of many messages and automatically invoked attachment interpretation has particularly high risk of substantial impact. 9. IANA Considerations This specification places no requirements on the IANA. 10. Relevant Publications The Elvin client protocol [ELVIN] defines an abstract protocol for communication between Elvin clients and Elvin routers, and concrete protocols for TCP-based Arnold Expires in 6 months [Page 11] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 transport and XDR-based data marshaling. A recommended extension to [ELVIN] providing automatic router discovery is defined in [ERDP]. An inter-router protocol wide-area routing [ERFP] are also available. Elvin router implementations normally support federation. 11. Contact for further information See section 13 for full contact details. 12. Author/Change controller This specification is a product of the informal Ticker- tape developer community. It is derived from work origi- nally done at DSTC (www.dstc.com), and now conducted through the facilities of tickertape.org with the cooper- ation of Mantara Software. Suggested revisions or extensions to this specification should be sent to the working group, at the address listed in section 13. Arnold Expires in 6 months [Page 12] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 13. REFERENCES [ELVIN] D. Arnold, Editor, "Elvin Client Access Proto- col", Work in progress [ERDP] D. Arnold, J. Boot, T. Phelps, B. Segall, "Elvin Router Discovery Protocol", Work in progress [ERFP] D. Arnold, I. Lister, "Elvin Router Federation Protocol", Work in progress [RFC1421] J. Linn, "Privacy Enhancement for Internet Elec- tronic Mail: Part I: Mesage Encryption and Authentication Procedures", RFC1421, February 1993. [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, November 1996. [RFC2046] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC2046, November 1996. [RFC2047] K. Moore, "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC2047, November 1996. [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Reg- istration Procedures", RFC2048, November 1996. [RFC2049] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC2049, November 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indi- cate Requirement Levels" RFC2119, March 1997. [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syn- tax Specifications: ABNF", RFC 2234, November 1997. Arnold Expires in 6 months [Page 13] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2483] M. Mealling, R. Daniel, Jr, "URI Resolution Ser- vices Necessary for URN Resolution", RFC 2483, January 1999. [UNICODE] Unicode Consortium, The, "The Unicode Standard, Version 4.0", Addison-Wesley, Reading, MA, 2003, ISBN 0-321-18578-1. 14. Contact Editor's Address David Arnold tickertape.org Email: ticker-dev@tickertape.org Contributors David Arnold Julian Boot Phil Cook Anna Gerber Michael Henderson Michael Lawley Ian Lister Thomas Maslen Ted Phelps Matthew Phillips Clinton Roy Bill Segall Martin Wanicki Arnold Expires in 6 months [Page 14] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 15. Full Copyright Statement Copyright (C) 2003-2004 by tickertape.org. Copyright (C) 2001-2003 DSTC Pty Ltd. All Rights Reserved. This specification may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, providing that the content remains unaltered, and that such distribution is under the terms of this licence. While every precaution has been taken in the preparation of this specification, the authors assume no responsibil- ity for errors or omissions, or for damages resulting from the use of the information herein. Comments on this specification are welcome. Please address any queries, comments or fixes (please include the name and version of the specification) to the mailing list below: ticker-dev@tickertape.org Elvin is a trademark of Mantara Software. All other trademarks and registered marks belong to their respec- tive owners. Arnold Expires in 6 months [Page 15] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 Appendix A - Example Notifications This section shows some example notifications using pre- vious versions of the Tickertape specification, and com- pares them with their representation using this version of the specification. Consider a simple message, with an attached URL: Message-Id: "1d906567-e491-48c6-9607-1b9f79f926da" TICKERTAPE: "Chat" TICKERTEXT: "check this out!" USER: "Spammeister" TIMEOUT: 5 MIME_TYPE: "x-elvin/url" MIME_ARGS: "http://www.spamradio.net" This would now be sent as Message-Id: "1d906567-e491-48c6-9607-1b9f79f926da" Group: "Chat" Message: "check this out!" From: "Spammeister" Timeout: 300 Attachment: "MIME-Version: 1.0\r\n" \ "Content-type:text/uri-list\r\n" \ "\r\n" \ "http://www.spamradio.net\r\n" User-Agent: "Example Ticker v1.0" The Attachment field is the most changed. It has been renamed, and is now a proper MIME document, rather than putting only the content type and the data as separate attributes. This makes for simpler handling using standard library facilities, and enables the proper use of all features from the MIME standards. Note also the recommended change from the experimental "x-elvin/url" content type, to the standard type "text/uri-list" when attaching a URL to a message. Also note that the Timeout field has changed from using units of minutes, to seconds. While minutes are suffi- cient resolution for this application, in other Elvin applications, Timeout normally uses seconds, and so that usage is adopted here. Arnold Expires in 6 months [Page 16] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 Appendix B - Previous Versions The protocol specified by this document has undergone several years of evolutionary development. Several dozen implementations exist, with varying levels of functional- ity and compatibility. The naming for attributes in this specification is delib- erately different from previous versions, in an attempt to both enable backward compatibility and to encourage migration to current best practice for Elvin applica- tions. Basic Attributes The basic attributes have remained unchanged since the first implementation of the Tickertape protocol for Elvin 3. All subsequent revisions have expanded on this basic set. Name Type Description ------------------------------------------------------- TICKERTAPE string The name of the group to which this message is sent. USER string The name of the sender of the message. TICKERTEXT string Text to be displayed in the scroller (or similar user inter- face location). TIMEOUT int32 Suggested lifetime of the mes- sage, in minutes, mostly useful for scrolling presentation. ------------------------------------------------------- Attachments The attachment of URLs to Tickertape messages was popu- larised using a debased form of MIME-style encoding. Few clients supported MIME types other than the informal 'x- elvin/url' type. Name Type Description --------------------------------------------------- MIME_TYPE string The MIME type of the attached data. MIME_ARGS string The body of the MIME object. --------------------------------------------------- Arnold Expires in 6 months [Page 17] Internet Draft Tickertape Chat Protocol v3 12 Apr 2004 Replacement Replacement of previous messages was introduced to sup- port sports scores and similar situations where a con- stantly updating value should not generate a new pre- sented message for each update. Name Type Description -------------------------------------------------------- REPLACEMENT string A string identifier. Subsequent messages with the same REPLACE- MENT value should replace this message when presented. -------------------------------------------------------- Threads The most recent addition to be widely implemented used message identifiers to allow a client to present responses to previous messages in order. This reflects the introduction of clients with tablular presentation instead of or in addition to a scrolling interface. Name Type Description -------------------------------------------------------- Message-Id string A string identifier for this message. Use of a UUID (GUID) is suggested. In-Reply-To string A string identifier for the mes- sage to which this is a response. -------------------------------------------------------- No other attributes have been widely accepted by develop- ers of Tickertape clients to date. This document repre- sents the first formal standardisation of the protocol, and codifies best-practice as developed by the Tickertape community over the course of these enhancements. Arnold Expires in 6 months [Page 18] From ticker-lists at lister.dnsalias.net Mon Apr 12 21:51:50 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Mon Apr 12 21:51:36 2004 Subject: [ticker-dev] Latest draft (was Re: Timeout attribute) In-Reply-To: Message-ID: An odd assortment: Originally we had a discussion about whether the Replaces attribute should refer to a specific previous message's Message-Id or whether it should be a seperate identifier that a sequence of messages would share. We went for the latter for a variety of reasons including supporting the ability to track the sequence of messages even if a consumer doesn't receive them all, and the supposed security benefits of being able to replace only those messages which were tagged for replacement at production time. I don't intend to revisit that decision, but I would like to set aside an appropriate attribute name for any protocol or application for which the Message-Id based methods is more appropriate (or which would like to use both methods). The reason I would like to do this as part of the Ticker spec process is that it may turn out that `Replaces' is the most appropriate name for this, and it would be better to use a different name for the Ticker-style method. Does anybody have any alternate name suggestions for either? At the risk of pushing my luck with the Timeout attribute I'd like to see a recommendation in the draft that producers not specify arbitrary message timeouts i.e. that unless there is a specific reason that the producer doesn't believe a message will have validity after a certain time then a Timeout should not be specified. This means that interactive clients would default to having an unspecified timeout for each message. The Distribution attribute is the only other one covered by the draft that I am uncertain about. Sticker uses CLASSIFIED and UNCLASSIFIED (and now `world'?) and DSTO filters traffic based on it, but I'm not aware of any other client implementation or organisation using it. I'm not particularly familiar with Sticker but IIRC it has a toggle control to choose between the two values, which are hard-coded into the application rather than configurable by the organisation (perhaps this has changed since I last looked though). It seems to me that any implementation which provides the functionality intended by the draft (that is, to allow organisations to define distribution scopes and to allow scopes to be chosen on a user's per-message basis rather than an administrator's per-channel basis) will be significantly more complicated, probably introducing a pull-down menu of known scopes. Currently, having the user select the correct channel can be difficult enough - with issues about discovering channels, getting the name exactly right (with associated case sensitivity nastiness), choosing the correct channel for the correct message (not leaking onto an inappropriate channel), etc - and it seems that introducing a scope menu would have all the same issues (currently without the equivalent of the presence protocol to discover scopes that other people are using) and would be similarly important in getting messages to the right people. Although breaking information up into discrete components is the content-based way it seems to me that in this case breaking the distribution apart from the topic are likely to add much more complication for users than the benefits justify. It is possible that this may not turn out to be the case, but my understanding of the current use of the Distribution attribute indicates that we don't yet have enough experience to be able to judge it. On the subject of behaviour specified by the draft, there are a few places where it should perhaps go further in dictating recommended behaviour. For example, section 6.1 recommends that clients use the Unicode features of Elvin `to ensure that user expectations are fulfilled' but provides no guidance in how that should be achieved. If the draft is recommending that all subscription references to the Group attribute should be wrapped in decompose() (or decompose-compat()? and maybe fold-case() as well?) that should be made explicit. Additionally, I think the standard attribute copying behaviours when replying to messages should be spelled out. For example, when sending a reply a client should use the same Group value as was contained in the message being replied to unless specifically instructed otherwise (which is especially important if clients use transformation functions in their Group subscriptions as above). Similarly, the Distribution of replies should default to the same value as the Distribution of the message they are in reply to. Finally, on a minor note, section 11 refers to section 13 for contact details, but should refer to section 14. Ian From arnold at dstc.edu.au Tue Apr 13 04:52:30 2004 From: arnold at dstc.edu.au (David Arnold) Date: Tue Apr 13 04:52:45 2004 Subject: [ticker-dev] Latest draft In-Reply-To: Your message of "Tue, 13 Apr 2004 12:51:50 +1000." Message-ID: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> <...> I would like to set aside an appropriate attribute name Ian> for any protocol or application for which the Message-Id based Ian> methods is more appropriate (or which would like to use both Ian> methods). The reason I would like to do this as part of the Ian> Ticker spec process is that it may turn out that `Replaces' is Ian> the most appropriate name for this, and it would be better to Ian> use a different name for the Ticker-style method. Does anybody Ian> have any alternate name suggestions for either? I think the name "Replaces" is a relic from the replace-by-id proposal. If I was to start from scratch, I'd suggest something like Replacement-For-Message-Id Replacement-Id Do sticker, aquatik or eTiks support Replaces/Replacement/REPLACEMENT ? Ian> At the risk of pushing my luck with the Timeout attribute I'd Ian> like to see a recommendation in the draft that producers not Ian> specify arbitrary message timeouts i.e. that unless there is a Ian> specific reason that the producer doesn't believe a message Ian> will have validity after a certain time then a Timeout should Ian> not be specified. This means that interactive clients would Ian> default to having an unspecified timeout for each message. The field is optional, so my reading would make this interpretation natural from the spec text itself .. if you have no need to indicate a useful lifetime of a message, then don't use a Timeout. Obviously existing clients tend to always include it, if only for reasons of unthinking compatibility with the original Elvin3 Python Tickertape GUI :-) I'm not sure this should be pushed via the spec? But maybe? Ian> The Distribution attribute is the only other one covered by the Ian> draft that I am uncertain about. Sticker uses CLASSIFIED and Ian> UNCLASSIFIED (and now `world'?) and DSTO filters traffic based Ian> on it, but I'm not aware of any other client implementation or Ian> organisation using it. Yet .. I'm fairly tempted to start Mantara using this, for example on "Chat" ... Ian> I'm not particularly familiar with Sticker but IIRC it has a Ian> toggle control to choose between the two values, which are Ian> hard-coded into the application rather than configurable by the Ian> organisation (perhaps this has changed since I last looked Ian> though). I think the values used to be set in a properties file? But I think you're right in that it uses a toggle button .. Matthew? Ian> It seems to me that any implementation which provides the Ian> functionality intended by the draft (that is, to allow Ian> organisations to define distribution scopes and to allow scopes Ian> to be chosen on a user's per-message basis rather than an Ian> administrator's per-channel basis) will be significantly more Ian> complicated, probably introducing a pull-down menu of known Ian> scopes. Currently, having the user select the correct channel Ian> can be difficult enough - with issues about discovering Ian> channels, getting the name exactly right (with associated case Ian> sensitivity nastiness), choosing the correct channel for the Ian> correct message (not leaking onto an inappropriate channel), Ian> etc - and it seems that introducing a scope menu would have all Ian> the same issues (currently without the equivalent of the Ian> presence protocol to discover scopes that other people are Ian> using) and would be similarly important in getting messages to Ian> the right people. I was disucssing this with Bill the other day, in the context of adding support for Distribution to xticker. We wanted two basic things: a) A reply to a message should default to the same Distribution as the original message b) Any message (reply or otherwise) using a non-default scope should highlight that fact fairly blatantly (not as blatanly as a confirmation dialog, but ... think vivid red panel or something) DSTC is one organisation that has (or used to have) three distribution scopes: internal, participant, and public, as an example. So something more than a simple toggle would be required there. There are a bunch of UI issues here which I don't think sticker (or eTiks, etc) has fully explored. Ian> Although breaking information up into discrete components is Ian> the content-based way it seems to me that in this case breaking Ian> the distribution apart from the topic are likely to add much Ian> more complication for users than the benefits justify. It is Ian> possible that this may not turn out to be the case, but my Ian> understanding of the current use of the Distribution attribute Ian> indicates that we don't yet have enough experience to be able Ian> to judge it. In general, I agree that a formal specification for Distribution is probably premature. I think the weasel words wrt legal values reflect this. My suggestion would be to move to it from its current position as "Optional" into a new section, "Experimental". I think there's some value in leaving it in the specification, so that at least we're noting the fact that there's a general concensus (and some implementation experience) with the field as named, although we might not be confident that it is in its final form? Ian> On the subject of behaviour specified by the draft, there are a Ian> few places where it should perhaps go further in dictating Ian> recommended behaviour. For example, section 6.1 recommends that Ian> clients use the Unicode features of Elvin `to ensure that user Ian> expectations are fulfilled' but provides no guidance in how Ian> that should be achieved. If the draft is recommending that all Ian> subscription references to the Group attribute should be Ian> wrapped in decompose() (or decompose-compat()? and maybe Ian> fold-case() as well?) that should be made explicit. A good question :-) I'm one of those people who is happy that "Chat" and "chat" are different things. I know there exist many people who think they're sufficiently similar that they should be considered the same thing in contexts like this. OTOH, there is historical precedent for not doing fold-case() on Group. Anyone want to oppose the forces of history on this? I'm unaware of any historical precedent for decomposition. Being an English-speaker, I'm hardly in a position to judge, but I'd probably suggest decompose-compat() if I had to guess. Anyone? Ian> Additionally, I think the standard attribute copying behaviours Ian> when replying to messages should be spelled out. For example, Ian> when sending a reply a client should use the same Group value Ian> as was contained in the message being replied to unless Ian> specifically instructed otherwise (which is especially Ian> important if clients use transformation functions in their Ian> Group subscriptions as above). Similarly, the Distribution of Ian> replies should default to the same value as the Distribution of Ian> the message they are in reply to. The Thread-Id behaviour could also be noted in such a section. I'll draft something. Ian> Finally, on a minor note, section 11 refers to section 13 for Ian> contact details, but should refer to section 14. Oops. I must M4 that one. Thanks. d From lawley at dstc.edu.au Tue Apr 13 05:45:32 2004 From: lawley at dstc.edu.au (michael j lawley) Date: Tue Apr 13 05:45:52 2004 Subject: [ticker-dev] Latest draft In-Reply-To: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> References: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> Message-ID: <407BC4CC.2060005@dstc.edu.au> David Arnold wrote: > Do sticker, aquatik or eTiks support Replaces/Replacement/REPLACEMENT ? aquatik has code to support it, but I don't think I've ever tested it since I don't have any clients that generate those fields. michael From lawley at dstc.edu.au Tue Apr 13 05:55:21 2004 From: lawley at dstc.edu.au (michael j lawley) Date: Tue Apr 13 05:55:40 2004 Subject: [ticker-dev] Latest draft In-Reply-To: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> References: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> Message-ID: <407BC719.3030808@dstc.edu.au> David Arnold wrote: > I was disucssing this with Bill the other day, in the context of > adding support for Distribution to xticker. > > We wanted two basic things: > > a) A reply to a message should default to the same Distribution as the > original message > > b) Any message (reply or otherwise) using a non-default scope should > highlight that fact fairly blatantly (not as blatanly as a > confirmation dialog, but ... think vivid red panel or something) > > DSTC is one organisation that has (or used to have) three distribution > scopes: internal, participant, and public, as an example. So > something more than a simple toggle would be required there. > > There are a bunch of UI issues here which I don't think sticker (or > eTiks, etc) has fully explored. Indeed, think about the current Chat / chat.world situation and all the hassle about federating Chat (and other channels) with ITEE. Support for Distribution would have easily alleviated most the problems involved and left the actual solution to the discretion of the individual poster. In fact, this concept may also improve the idea of the channel if things were switched around to be the "personal" channel with Distribution . michael From bill at segall.net Tue Apr 13 06:41:44 2004 From: bill at segall.net (Bill Segall) Date: Tue Apr 13 06:41:55 2004 Subject: [ticker-dev] Latest draft In-Reply-To: <407BC719.3030808@dstc.edu.au> Message-ID: > In fact, this concept may also improve the idea of the > channel if things were switched around to be the "personal" > channel with Distribution . The idea of personal hadn't occured to me and I like it a lot. I (unsurprisingly) run a personal Elvin router and a lot of my personal instrumentation/info groups could really benefit from a "scope of me". e.g., I currently have a cvs group and a bill.cvs group instead of a cvs group with distributions of "me" and "mantara". Thinking further, my distribution falls into several catgeories and without wanting to get into an ontological war I have the rough broad categorisations: personal: just me work: colleagues/corporate world: everybody Between the gaps, I also like to distribute stuff to some selected individuals on a case by case basis. An example is the conversations I might have with Ruth and I currently accomplish this with Elvin security which in some ways is a more appropriate mechanism. The bit I don't understand with this group is the gap between distribution and security. This traffic is always restricted to my local router but other private and secured groups I have are distributed. It's almost as though I need a: security: "list of federation rules" to add to the above list. I'd also like a: friends: a kind of buddy list system With this view, the "work" distribution is also just a special group of people, and in fact if I had a broader ability to specify groups of interest I might choose it. Before we begin to specify distribution lists which could become a nightmare, what I'm wondering about is how the UI might allow me to specify what I wanted without worrying (yet) about the underlying mechanism. >From a UI point of view, I currently find "leakage" to be a problem. Leakage seems to be a phenomenen of CBR in some ways - it's as though we have this terrific routing ability but we can't manage to get the UI to obey what our brains are thinking. How can we build a UI to specify what we want, how do we trap mistakes to ask users without it being intrusive, how can we inform users *before* they post about what they are actually doing? Once we have these ideas in place, how do the messages contain attributes that more easily manage the routing choices? (and from a Mantara perspective, how do we easily manage fderation rules once we've made those decisions?) Is a dropdown menu significantly harder than a toggle button? Can colour help? Once I've received a message how can I tell it's distribution so I don't accidentally blurt out someone's secret? Could I help leakage by having a replace option on reply so that I can "cancel" my previous message? --- the number of times I've wanted that :-) Experimental would seem like a great plan from the specification viewpoint. I think this could go a long wat to encourage a new era of trying things out. I suspect that part of the problem is that we're way too focussed on getting this spec "right". Perhaps we should just close it out and then start on the next version. Specs are great things but there needs to be revisions and new versions as well. Bill. From arnold at dstc.edu.au Tue Apr 13 09:31:20 2004 From: arnold at dstc.edu.au (David Arnold) Date: Tue Apr 13 09:31:30 2004 Subject: [ticker-dev] Latest draft In-Reply-To: Your message of "Tue, 13 Apr 2004 20:55:21 +1000." <407BC719.3030808@dstc.edu.au> Message-ID: <200404131431.i3DEVIT8024430@piglet.dstc.edu.au> -->"michael" == michael j lawley writes: >> DSTC is one organisation that has (or used to have) three >> distribution scopes: internal, participant, and public, as an >> example. So something more than a simple toggle would be >> required there. michael> Indeed, think about the current Chat / chat.world situation michael> and all the hassle about federating Chat (and other michael> channels) with ITEE. Exactly. michael> Support for Distribution would have easily alleviated most michael> the problems involved and left the actual solution to the michael> discretion of the individual poster. Depending on how it's used, yes. michael> In fact, this concept may also improve the idea of the michael> channel if things were switched around to be the michael> "personal" channel with Distribution . This would only really work if organisations were happy to use a default-allow policy. Internal-only traffic would need to have Distribution "internal" (or whatever) and would be blocked at the organisational boundary. The other question is whether the Distribution value should be a list, or a single value. I'm not sure there's a good use for a list ... ? d From ticker-lists at lister.dnsalias.net Tue Apr 13 20:35:47 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Apr 13 20:35:36 2004 Subject: [ticker-dev] Latest draft In-Reply-To: <200404130952.i3D9qTT8005451@piglet.dstc.edu.au> Message-ID: On Tue, 13 Apr 2004, David Arnold wrote: >I think the name "Replaces" is a relic from the replace-by-id proposal. It does seem more appropriate for that, yes. (Which is of course why I raised it :-) >If I was to start from scratch, I'd suggest something like > > Replacement-For-Message-Id > Replacement-Id Would you be interested in renaming the current Replaces then? [Re: Timeout] >The field is optional, so my reading would make this interpretation >natural from the spec text itself .. if you have no need to indicate a >useful lifetime of a message, then don't use a Timeout. I see what you're saying, but my reading of the fact that it's optional is just to say `you can do this if you want' but that doesn't really imply `you shouldn't do this unless you have a good reason', and I think it's worth making the second part explicit. >Obviously existing clients tend to always include it, if only for >reasons of unthinking compatibility with the original Elvin3 Python >Tickertape GUI :-) I think existing clients tend to always include it because (a) of a `more is better' perception (it's optional, and I _can_ do it easily enough, so I should), and (b) everybody else does (more about following the herd than compatibility). >I'm not sure this should be pushed via the spec? But maybe? I could possibly be convinced that it shouldn't, but currently I think it's well within the scope of the spec to be making clear anything (including implementation issues) that improves the effectiveness of the protocol. > Ian> The Distribution attribute is the only other one covered by the > Ian> draft that I am uncertain about. Sticker uses CLASSIFIED and > Ian> UNCLASSIFIED (and now `world'?) and DSTO filters traffic based > Ian> on it, but I'm not aware of any other client implementation or > Ian> organisation using it. > >Yet .. I'm fairly tempted to start Mantara using this, for example on >"Chat" ... My point was not that it's not generally useful, just that it's not generally used (yet), and I am reluctant to standardise (even in a weasel-word way) anything that we don't have enough experience with to be confident in. >I was disucssing this with Bill the other day, in the context of >adding support for Distribution to xticker. > >We wanted two basic things: > >a) A reply to a message should default to the same Distribution as the > original message I think that's pretty much a given (and is something the spec should make explicit). >b) Any message (reply or otherwise) using a non-default scope should > highlight that fact fairly blatantly (not as blatanly as a > confirmation dialog, but ... think vivid red panel or something) So I would have Chat configured by default to be Mantara-internal, and any conversation I have on `chat.world' (Group: "Chat" Distribution: "world") would have vivid red over everything? Hmmm... could be a lot of UI experimentation there to get something that works well :-) >DSTC is one organisation that has (or used to have) three distribution >scopes: internal, participant, and public, as an example. So >something more than a simple toggle would be required there. Definitely. The mechanism is designed to support an arbitrary set of values and I think that for the purposes of interoperability that means all clients are going to need to support that too. Note that this isn't strictly an optional extra to the protocol; I think any interactive client MUST support it at least to the extent that any Distribution is copied from original message to reply. Otherwise there will be breakage where a user replies to a message on `chat.world' and sees their own reply but nobody on the other side of any administrative boundary does. Note that a client such as psst (which has the consumer and producer components completely separated) is fundamentally unable to do this. >There are a bunch of UI issues here which I don't think sticker (or >eTiks, etc) has fully explored. I agree. >In general, I agree that a formal specification for Distribution is >probably premature. I think the weasel words wrt legal values reflect >this. > >My suggestion would be to move to it from its current position as >"Optional" into a new section, "Experimental". Yep, I think that's something along the lines of what I was thinking of. Either that or add it later as subsequent additional spec (but note the observation above that this isn't going to work unless all clients support it to some extent). >I think there's some value in leaving it in the specification, so that >at least we're noting the fact that there's a general concensus (and >some implementation experience) with the field as named, although we >might not be confident that it is in its final form? I think if we're not confident that it's right yet (or may change) it probably shouldn't be covered in the spec in any formal way. [Re: using the Unicode features of Elvin to fulfil user expectations] >I'm one of those people who is happy that "Chat" and "chat" are >different things. I know there exist many people who think they're >sufficiently similar that they should be considered the same thing in >contexts like this. > >OTOH, there is historical precedent for not doing fold-case() on Group. And historical evidence that it causes problems, even with users who are well aware of the need to be careful of case. I'm not aware of any cases where it has proved to be an advantage. Fortunately the negative transitional effects of making the change would (IMO) be reaonsably small, and limited to users of old clients potentially not seeing messages sent by new clients on channels with different case. As long as replies copy the group name from the original message then this should be kept to an absolute minimum. Note that this is the same as introducing any recommendation of decomposing group names in subscriptions. >Anyone want to oppose the forces of history on this? Well, the historical precedent is for us to break stuff willy-nilly in the name of making it better for the future, so given the small impact I'm not too concerned about the negative effects of changing this. >I'm unaware of any historical precedent for decomposition. Being an >English-speaker, I'm hardly in a position to judge, but I'd probably >suggest decompose-compat() if I had to guess. Anyone? So what exactly was the last paragraph of section 6.1 recommending? On Tue, 13 Apr 2004, Bill Segall wrote: >Experimental would seem like a great plan from the specification >viewpoint. I think this could go a long wat to encourage a new era of >trying things out. I suspect that part of the problem is that we're way >too focussed on getting this spec "right". Perhaps we should just close >it out and then start on the next version. Specs are great things but >there needs to be revisions and new versions as well. I definitely agree. The problem with Distribution is that it requires _all_ clients to support it for it to work properly :-/ On Wed, 14 Apr 2004, David Arnold wrote: > michael> In fact, this concept may also improve the idea of the > michael> channel if things were switched around to be the > michael> "personal" channel with Distribution . > >This would only really work if organisations were happy to use a >default-allow policy. Internal-only traffic would need to have >Distribution "internal" (or whatever) and would be blocked at the >organisational boundary. I think any significant administrative boundary (such as at the boundary of a company) would have to have a default-deny on Distribution. Of course, the problem is dealing with messages that don't have specified Distributions without but-not(). >The other question is whether the Distribution value should be a list, >or a single value. I'm not sure there's a good use for a list ... ? I can see quite a few uses, but it always seems so ugly in the absence of native lists. One good example of a use would be where we have a group for communication with a specific customer or participant. In that case the distribution should list the two specific organisations involved. Another is Bill's example of communicating with a specific person. However, it's not clear whether these problems are best solved with Distribution or with some other approach (keys, Reply-To, etc). Ian From ticker-lists at lister.dnsalias.net Tue Apr 13 20:39:44 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Apr 13 20:39:43 2004 Subject: [ticker-dev] Leakage (was Re: Latest draft) In-Reply-To: Message-ID: On Tue, 13 Apr 2004, Bill Segall wrote: >From a UI point of view, I currently find "leakage" to be a problem. >Leakage seems to be a phenomenen of CBR in some ways Not necessarily. It occurs in channel based communication too (which is what Ticker is for the most part, anyway). As you pointed out it's largely a UI issue, but not strictly so. For example leakage in Ticker, IRC and other forms of IM is because either (a) you type in the same place regardless of where you're sending your message and don't pay enough attention to the drop-down menu or equivalent, or (b) you have several similar windows open that you're switching between and typing in and the wrong one has focus. (a) is easier to do, but (b) occurs even in non-messaging scenarios e.g. typing into the wrong terminal window. Note that other messaging systems that don't usually have the leakage problem are because you interact with them in different ways e.g. when writing email to mailing lists one needs to explicitly choose the destination for each message (or reply to an existing one on the right list) and one usually spends more time and concentration on each message than in IM. Before I get too carried away in rambling, I'll just list a few (primarily UI) issues that I think combine to increase the risk of leakage in Ticker: (1) All typing goes into the same location on screen, regardless of the destination of the message. (2) It can be easy to accidentally slip and choose the wrong item from a popup menu (much harder than when typing in a destination address). (3) Messages are short and conversations can be fast, leading to not as much time spent checking over the message before sending. (4) There is always a group selected (no requirement to explicitly select a group before sending, even for the first message in a thread). ...and probably a bunch of others. Ian From Matthew.Phillips at dsto.defence.gov.au Thu Apr 15 20:29:12 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Apr 15 20:34:11 2004 Subject: [ticker-dev] Latest draft Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10D3@ednex502.dsto.defence.gov.au> [David] > Do sticker, aquatik or eTiks support > Replaces/Replacement/REPLACEMENT ? I haven't implemented this in Sticker, partly due to the fact that I don't have anything that would use it and partly due to the possible hackability opened up by the feature. One solution to the latter might be to mark messages intended to be replaced with an attribute. > Ian> At the risk of pushing my luck with the Timeout attribute I'd > Ian> like to see a recommendation in the draft that producers not > Ian> specify arbitrary message timeouts i.e. that unless there is a > Ian> specific reason that the producer doesn't believe a message > Ian> will have validity after a certain time then a Timeout should > Ian> not be specified. This means that interactive clients would > Ian> default to having an unspecified timeout for each message. > > The field is optional, so my reading would make this interpretation > natural from the spec text itself .. if you have no need to indicate a > useful lifetime of a message, then don't use a Timeout. > > Obviously existing clients tend to always include it, if only for > reasons of unthinking compatibility with the original Elvin3 Python > Tickertape GUI :-) > > I'm not sure this should be pushed via the spec? But maybe? A note about only including it when it has meaning might be good. > Ian> The Distribution attribute is the only other one covered by the > Ian> draft that I am uncertain about. Sticker uses CLASSIFIED and > Ian> UNCLASSIFIED (and now `world'?) and DSTO filters traffic based > Ian> on it, but I'm not aware of any other client implementation or > Ian> organisation using it. > > Yet .. I'm fairly tempted to start Mantara using this, for example on > "Chat" ... My current usage is "Distribution: world" for allowing a message outside, which should make sense at most sites. The older UNCLASSIFIED: 1 and Classification: UNCLASSIFIED will be retired when the v1 format is. > Ian> I'm not particularly familiar with Sticker but IIRC it has a > Ian> toggle control to choose between the two values, which are > Ian> hard-coded into the application rather than configurable by the > Ian> organisation (perhaps this has changed since I last looked > Ian> though). > > I think the values used to be set in a properties file? But I think > you're right in that it uses a toggle button .. Matthew? It does use a toggle (to be a checkbox in 3.1) to set this. The value that gets attached will be settable in 3.1 also (currently it's hardwired). > We wanted two basic things: > > a) A reply to a message should default to the same Distribution as the > original message Sounds reasonable. However I'd agree with Ian's comment about confusing lists of scopes (snipped). The key problem we're trying to solve is the selective restriction of messages to a local site. Support for lists of (possibly nested) distribution scopes seem like a good idea to us computer scientists, but not many people (Bill excluded ;) would actually use this, so I'd think the cognitive overhead of adding all this to the UI wouldn't pay off. By boiling it down to a boolean "world" flag for messages, Sticker keeps it simple and fairly obvious - this apprpach has proven itself over extended use. However, I'd be open to the idea of allowing multple scopes (eg local, participant and world) choosable by a combo box if explicitly set in the site config. So I'd suggest at least two defined values for Distribition: "local" and "world". > My suggestion would be to move to it from its current position as > "Optional" into a new section, "Experimental". I'd like to leave it as an optional field. > I'm one of those people who is happy that "Chat" and "chat" are > different things. I know there exist many people who think they're > sufficiently similar that they should be considered the same thing in > contexts like this. > Anyone want to oppose the forces of history on this? Yes, please :) I'm one of those people that like the "case-preserving but not case-sensitive" approach for names that people refer to things by. Unlike in programming languages, I can't see a good reason to consider CHAT and Chat to be different groups. I realise case-insensitivity is complex outside of the Roman alphabet, but I'm willing to deal with that if a bunch of irate Arabic speakers complain ;) Cheers, Matthew. From Matthew.Phillips at dsto.defence.gov.au Thu Apr 15 21:24:38 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Apr 15 21:29:07 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10D5@ednex502.dsto.defence.gov.au> The updated spec looks fine to me. Two things though: * We should add a note about org.tickertape.message:3000 differences, especially the change in Timeout from minutes to seconds. * We've gone back to "Attachment"? Not that I mind, but didn't we have an exchange which resulted in going from Attachment to MIME-Attachment a while ago? Also, using string disallows some MIME encodings. I'd be inclined to allow opaque or string for this field. Cheers, Matthew. > -----Original Message----- > From: David Arnold [mailto:david@mantara.com] > Sent: Monday, 12 April 2004 11:38 AM > To: ticker-dev@tickertape.org > Subject: Re: [ticker-dev] Timeout attribute > > > -->"Matthew" == Phillips, Matthew > writes: > > Matthew> So, to get some closure here, how about I post my +1 for > Matthew> the "org.tickertape.message: 3001" proposal? Any > Matthew> dissenters? > > I'm happy with this. > > I've attached the current draft of the specification, updated to > reflect what I believe is the consensus position on all attributes. > > This would be a good time for everyone to read it, carefully, cover to > cover, and object to anything you find objectionable :-) > > > > > d > > > From arnold at dstc.edu.au Sun Apr 18 16:59:49 2004 From: arnold at dstc.edu.au (David Arnold) Date: Sun Apr 18 17:00:06 2004 Subject: [ticker-dev] Is this software usable? Message-ID: <200404182159.i3ILxlA9020035@piglet.dstc.edu.au> Hi John, I have forwarded your mail to the general Tickertape developers list (the announcements list is not open for public postings). John> I just downloaded this software. I am getting a scroller window John> on my desktop but can do virtually nothing with it. How can I John> connect to the Ervin server? It will not connect. How can I John> extend the length of the scroller window? How can I add to the John> news groups? Is there online help available? Is there a FAQ John> list? Help. There are many different Tickertape client programs, each with different ways of configuring preferred behaviour -- which one have you downloaded? d From david at mantara.com Sun Apr 18 23:02:18 2004 From: david at mantara.com (David Arnold) Date: Sun Apr 18 23:02:27 2004 Subject: [ticker-dev] viewcvs Message-ID: fyi, i have installed cvsgraph and viewcvs on laika. http://www.tickertape.org/cgi-bin/viewcvs.cgi Mantara is working through the legalities of re-releasing some of its intellectual property via tickertape.org. this will allow all the old DSTC ticker stuff to move. we should have it sorted within a few weeks. d From ticker-lists at lister.dnsalias.net Mon Apr 19 01:02:49 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Mon Apr 19 01:02:34 2004 Subject: [ticker-dev] Latest draft In-Reply-To: <6949B1A32630D811B8CB00306E013ADE0A10D3@ednex502.dsto.defence.gov.au> Message-ID: On Fri, 16 Apr 2004, Phillips, Matthew wrote: >[David] >> Do sticker, aquatik or eTiks support >> Replaces/Replacement/REPLACEMENT ? > >I haven't implemented this in Sticker, partly due to the fact that I >don't have anything that would use it and partly due to the possible >hackability opened up by the feature. One solution to the latter might be >to mark messages intended to be replaced with an attribute. They are. The Replacement attribute. (Or Replaces or whatever it is) It refers to a previous replacement value, not to a Message-Id (for exactly this reason). >Yes, please :) I'm one of those people that like the "case-preserving but >not case-sensitive" approach for names that people refer to things by. >Unlike in programming languages, I can't see a good reason to consider >CHAT and Chat to be different groups. I realise case-insensitivity is >complex outside of the Roman alphabet, but I'm willing to deal with that >if a bunch of irate Arabic speakers complain ;) I don't think the internationalisation issues should be too bad. The subscription language provides the fold-case function, which uses the Unicode case folding tables in the router, which we trust the Unicode people have done a good job of making sure works appropriately across all languages and character sets. I'm pretty confident we won't end up with irate Arabic speakers by making things case insensitive, but I sometimes get irate about all the English speakers who have difficulties because of the case sensitivity... ;-) Ian From arnold at dstc.edu.au Mon Apr 19 03:25:52 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Apr 19 03:26:05 2004 Subject: channel subscription rules (was: Re: [ticker-dev] Latest draft) In-Reply-To: Your message of "Mon, 19 Apr 2004 16:02:49 +1000." Message-ID: <200404190825.i3J8PoA9011169@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> I'm pretty confident we won't end up with irate Arabic speakers Ian> by making things case insensitive, but I sometimes get irate Ian> about all the English speakers who have difficulties because of Ian> the case sensitivity... ;-) i think everyone is now used to dealing with systems that take the approach of requiring precise use of capitalisation, and those that have decided that such precision is unnecessary. so, if there are people who feel strongly that requiring ticker clients to subscribe using fold-case() is the right approach, i'd be willing to entertain proposals for such an amendment to the spec (in the next few days :-) with regard to decomposition, i suppose Ian has the best knowledge of Unicode amongst us? Ian, what would you suggest is most likely to annoy the fewest people? d From arnold at dstc.edu.au Mon Apr 19 03:36:54 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Apr 19 03:37:02 2004 Subject: [ticker-dev] up2date Message-ID: <200404190836.i3J8aqA9011910@piglet.dstc.edu.au> until now we have been managing the packages on both euler and laika using apt (and repositories from freshrpms and ev1 respectively). however, i have noticed that the apt repository for laika has not been kept up to date. i asked the ev1 admins about this, and was told that they had stopped updating it, and had instead made a deal with Red Hat for their customers to have access to Red Hat's up2date service. so ... i've had laika configured to use up2date. the consequence of this, for those not familiar with it, is that to install a new package, you should do up2date --nox -i package-name and the download and install all available updates, the syntax is up2date --nox -u i installed all available packages this morning, but it is ignoring kernel packages at the moment. i'm tempted to tell it not to do that as well, and will do so unless someone tells me otherwise in the next few days ... fyi, etc, d From ticker-lists at lister.dnsalias.net Mon Apr 19 07:30:27 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Mon Apr 19 07:30:19 2004 Subject: channel subscription rules (was: Re: [ticker-dev] Latest draft) In-Reply-To: <200404190825.i3J8PoA9011169@piglet.dstc.edu.au> Message-ID: On Mon, 19 Apr 2004, David Arnold wrote: >i think everyone is now used to dealing with systems that take the >approach of requiring precise use of capitalisation, and those that >have decided that such precision is unnecessary. I don't think they are. In fact I'm damn sure they're not :-) Your average computer user doesn't deal with a great deal of computer systems that require precise use of capitalisation. DOS/Windows systems traditionally don't require it anywhere and the main way it has potential to leak in is from Unix systems, specifically on the Internet. However, even most commonly used systems on the Internet (i.e. web and mail) don't particularly care about it: neither DNS nor mail usernames are case sensitive, and by the time people need to specify directory paths in URLs they're more often cutting and pasting or just clicking than having to type from scratch. In fact the only place a normal non-Unix user is likely to come across case sensitivity is in passwords, and I seem to recall at least some versions of Microsoft products (things like AD, not just the old toy-like, completely insecure versions of Windows) use case-insensitive passwords. But even aside from the pseudo-reasoning and speculation on how the other half lives, my own experience dealing with technical users in a Unix (or at least Unix-aware) environment (i.e. DSTC) has pretty firmly convinced me that if usability is even a small priority for Tickertape it should be case insensitive. >with regard to decomposition, i suppose Ian has the best knowledge of >Unicode amongst us? Ian, what would you suggest is most likely to >annoy the fewest people? I'm far from an expert on the subject, but I'll venture a slightly-better-than-guess opinion. Unless we are going to completely ignore the issue, I think recommending canonical decomposition is extremely important if we ever deal in non-ASCII group names (as hopefully we should). I also very strongly recommend compatibility decomposition, even more so than case folding. The reason for this is that canonically equivalent character sequences are completely indistinguishable (without looking at the code points used to represent them), and that compatibility equivalent character sequences are only subtly different (and may not appear at all different in many fonts). On the basis that a user should be able to look at a group name and reproduce it elsewhere I think it's worth using compatibility decomposition. Ian From arnold at dstc.edu.au Mon Apr 19 17:32:56 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Apr 19 17:33:07 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: Your message of "Mon, 19 Apr 2004 22:30:27 +1000." Message-ID: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> <...> my own experience dealing with technical users in a Unix Ian> (or at least Unix-aware) environment (i.e. DSTC) has pretty Ian> firmly convinced me that if usability is even a small priority Ian> for Tickertape it should be case insensitive. without necessarily disagreeing with you, i'd argue that the problem is potentially more that we're requiring people to transcribe strings. people are bad at copying things exactly -- regardless of whether it is getting the case of letters right, or just getting all the right characters in the right order. there are several methods that are widely used to assist people with this task: filename completion in shells, variable/method/class name popups in IDEs, URL completion (from history) in browsers, drop-down combo box widgets, etc. in considering the tradeoff between usability and efficient evaluation, i'm not convinced that making the router do fold-case(Group) == fold-case("MyChannelName") instead of Group == "MyChannelName" is worth the usability outcome. i believe the fundamental problem lies in the UI where we require users to accurately transcribe strings. Ian> <...> and by the time people need to specify directory paths in Ian> URLs they're more often cutting and pasting or just clicking Ian> than having to type from scratch. exactly. i've long felt that Tickertape needed to move away from a model of requiring users to type in group names and towards using a MIME type for channel descriptions (ie. my short presentation on this topic at the 2001 workshop). this would simplify the process of mailing and tickering groups for subscription, allowing a click-to-subscribe UI. it also has the side-effect of reducing the need for the users to distinguish between their A's and their a's. which is not to say that we shouldn't specify that group names should be matching using fold-case(), just that i'm not yet convinced that a justification of "users can't get case right" is sufficient to require all Tickertape subscriptions to be more complex. Ian> I think recommending canonical decomposition is extremely Ian> important if we ever deal in non-ASCII group names (as Ian> hopefully we should). i agree that we should support non-ASCII group names. Ian> I also very strongly recommend compatibility decomposition, Ian> even more so than case folding. The reason for this is that Ian> canonically equivalent character sequences are completely Ian> indistinguishable (without looking at the code points used to Ian> represent them), and that compatibility equivalent character Ian> sequences are only subtly different (and may not appear at all Ian> different in many fonts). On the basis that a user should be Ian> able to look at a group name and reproduce it elsewhere I think Ian> it's worth using compatibility decomposition. so you'd recommend decompose-compat(Group) == decompose-compat("MyChannelName") as the basic pattern for subscriptions? (potentially with fold-case wrapped around or inside that) d From matthew.phillips at dsto.defence.gov.au Wed Apr 21 02:36:51 2004 From: matthew.phillips at dsto.defence.gov.au (Matthew Phillips) Date: Wed Apr 21 02:44:46 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> References: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> Message-ID: <40862493.5000108@dsto.defence.gov.au> David Arnold wrote: >in considering the tradeoff between usability and efficient >evaluation, i'm not convinced that making the router do > > fold-case(Group) == fold-case("MyChannelName") > >instead of > > Group == "MyChannelName" > >is worth the usability outcome. > I'd argue yes, especially since I'm assuming that this isn't a particularly high-overhead operation? btw does the server optimize the "fold-case('MyChannelName')" to "mychannelname"? >i've long felt that Tickertape needed to move away from a model of >requiring users to type in group names and towards using a MIME type >for channel descriptions (ie. my short presentation on this topic at >the 2001 workshop). this would simplify the process of mailing and >tickering groups for subscription, allowing a click-to-subscribe UI. > > A MIME encoding for subscriptions would be useful. But, in practice, an effective way to "share" groups is already available via presence. Most of the people using Sticker never type in a group name: they select groups that other people are already subscribed to. It's why I've been hassling Martin to get eTiks to emit the Ticker-Groups and News-Groups fields in presence. I'm actually a little surprised that eTiks and Aquatik haven't taken advantage of this information in their subscription UI's, given that the information comes pretty much for free if you're doing presence anyway. I realise that this technique doesn't support complex subscriptions, but I think that sort of subscription is less likely to be shared. Matthew. From phelps at gnusto.com Wed Apr 21 06:24:20 2004 From: phelps at gnusto.com (Ted Phelps) Date: Wed Apr 21 06:24:23 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: Your message of Wed, 21 Apr 2004 17:06:51 +0930. <40862493.5000108@dsto.defence.gov.au> References: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> <40862493.5000108@dsto.defence.gov.au> Message-ID: <200404211124.i3LBOKKH013614@gnusto.com> [Apologies if you receive this twice. I've had an argument with pipermail, which I may have won. :-)] Matthew Phillips may have said: > btw does the server optimize the "fold-case('MyChannelName')" to > "mychannelname"? Yes, and it will cache the results of a 'fold-case(Group)' during evaluation, so the router will only incur the case-folding overhead once per notification. In other words, for m subscriptions and n notifications, there would be m + n total calls to 'fold-case()'. Cheers, -Ted From phelps at gnusto.com Wed Apr 21 06:16:53 2004 From: phelps at gnusto.com (Ted Phelps) Date: Wed Apr 21 07:59:21 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: Your message of Wed, 21 Apr 2004 17:06:51 +0930. <40862493.5000108@dsto.defence.gov.au> References: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> <40862493.5000108@dsto.defence.gov.au> Message-ID: <200404211116.i3LBGrOI013454@gnusto.com> Matthew Phillips may have said: > btw does the server optimize the "fold-case('MyChannelName')" to > "mychannelname"? Yes, and it will cache the results of a 'fold-case(Group)' during evaluation, so the router will only incur the case-folding overhead once per notification. In other words, for m subscriptions and n notifications, there would be m + n total calls to 'fold-case()'. Cheers, -Ted From ticker-lists at lister.dnsalias.net Thu Apr 22 22:32:50 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Thu Apr 22 22:32:39 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: <200404192232.i3JMWsA9010110@piglet.dstc.edu.au> Message-ID: On Tue, 20 Apr 2004, David Arnold wrote: >people are bad at copying things exactly -- regardless of whether it >is getting the case of letters right, or just getting all the right >characters in the right order. Yep, so making it easier for them is important. Getting letters in the right order is a lot more basic than getting their case right. As long as you're dealing with ordinary single words (even if they're joined together DNS-style) then people are usually pretty good at spelling, but case is still pretty much an arbitrary choice (and some people will even still put things in all upper case, just because they don't realise that's the done thing). >in considering the tradeoff between usability and efficient >evaluation, i'm not convinced that making the router do > > fold-case(Group) == fold-case("MyChannelName") > >instead of > > Group == "MyChannelName" > >is worth the usability outcome. Probably because we attach different relative importance to usability and saving CPU cycles ;-) > i believe the fundamental problem >lies in the UI where we require users to accurately transcribe >strings. To pass the issue off to the UI would mean we would have to have made sure that we'd provided everything in the protocol that the UI would need, and that our expectations of the UI are realistic. I don't think that we've done either of these. We have a means whereby group names can be communicated using the presence protocol, assuming two users are already in the same presence group, but this effectively just pushes the problem from finding correct ticker group names to finding correct presence group names. While Sticker may be a model citizen in implementing many of these new protocol features (they seem to have a tendency to go from Sticker to the protocol rather than the other way around) most of the other clients are either very slow to implement them or have no plans to implement them. For example, I believe Ted doesn't think XTickertape should implement the presence protocol, or even move away from text file configuration. Unless these UI changes actually have some chance of happening, it's only fair to make the protocol itself friendlier as well. (And Matthew, who's off in Sticker-land, still sees the need for case-insensitive group names). Also, while we can add mechanisms (such as integrated presence/ticker) that allow people to bypass manual transciption in many circumstances, there are many other circumstances where group names are best carried by some non-digital (or otherwise non-automatable) means. > Ian> <...> and by the time people need to specify directory paths in > Ian> URLs they're more often cutting and pasting or just clicking > Ian> than having to type from scratch. > >exactly. ... _because_ by that point so they're so long and complicated people don't try to remember them. Ticker group names aren't so long and complicated that they preclude the possibility of humans remembering them and/or transmitting them verbally, and I don't think they should (or will) be. >so you'd recommend > > decompose-compat(Group) == decompose-compat("MyChannelName") > >as the basic pattern for subscriptions? (potentially with fold-case >wrapped around or inside that) Yep. Ian From ticker-lists at lister.dnsalias.net Thu Apr 22 23:00:10 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Thu Apr 22 22:59:54 2004 Subject: channel subscription rules (was: Re: [ticker-dev] Latest draft) In-Reply-To: <200404190825.i3J8PoA9011169@piglet.dstc.edu.au> Message-ID: On Mon, 19 Apr 2004, David Arnold wrote: >so, if there are people who feel strongly that requiring ticker >clients to subscribe using fold-case() is the right approach, i'd be >willing to entertain proposals for such an amendment to the spec (in >the next few days :-) I suggest the following amendment: In section 6.1, replace the following text: The Elvin subscription language provides operations to transform strings to canonical representations to ensure that strings using different representations of the same characters are correctly matched. Implementors of Tick- ertape protocol clients SHOULD use these features to ensure that user expectations are fulfilled. with: The Elvin subscription language provides operations to transform strings to canonical representations to ensure that strings using different representations of the same characters are correctly matched. Implementations of the Tickertape protocol MUST use the decompose-compat and fold-case subscription langage functions to normalise references to the 'Group', 'From' and 'Message' attributes unless explicitly instructed to the contrary by the user. For example, a subscription to a group named 'Chat' would be made with the expression: fold-case(decompose-compat(Group)) == fold-case(decompose-compat("Chat")) When sending a message as a reply to a previously received message, implementations MUST set the value of the 'Group' attribute in the reply to be exactly the same as the value of the 'Group' attribute in the message to which it is a reply unless explicitly instructed to reply in a different group. Ian From Matthew.Phillips at dsto.defence.gov.au Fri Apr 23 00:16:35 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Fri Apr 23 00:25:09 2004 Subject: [ticker-dev] Re: channel subscription rules Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10EB@ednex502.dsto.defence.gov.au> > While Sticker may be a model citizen in implementing many of these new > protocol features (they seem to have a tendency to go from > Sticker to the > protocol rather than the other way around) I hope the impression isn't that I'm doing the equivalent of what Netscape did to HTML ;) My work with Sticker seems to be the most active in the ticker client arena right now (other people having moved on to more important things ;), so it shouldn't be too surprising that a lot of new ideas are coming from here. > most of the other > clients are > either very slow to implement them or have no plans to > implement them. For > example, I believe Ted doesn't think XTickertape should implement the > presence protocol, or even move away from text file > configuration. Unless > these UI changes actually have some chance of happening, it's > only fair to > make the protocol itself friendlier as well. (And Matthew, > who's off in > Sticker-land, still sees the need for case-insensitive group names). While it can hard as a client author to make observations without appearing biased, I'm going to go ahead and potentially insert foot A into mouth B anyway. I think it's possible, likely even, that some of the people on this list who have been using ticker from The Beginning, and now have it built into their limbic reflexes, don't fully appreciate how much _integrated_ presence adds to the way tickertape works. It's not just a new feature tacked on the side: it makes a significant difference to be able to see what channels are being used or who's listening to a given channel, and hence the minimum audience for a message. Being able to see a person is there and send them a message directly (and being warned if they're offline or away) is also a key new feature and used a lot here at DSTO: probably more than 80% of the chat traffic here is person-to-person (for reference, we have about 25-30 regular users right now). (interestingly, a number of people use subscriptions to look for words of interest across groups and it's not uncommon for people to pop up in previously one-on-one conversations). Other things, such as being able to see that someone is "Replying..." allows you to stop "talking over" them or to see that they probably saw the message you just sent them. By doing fairly simple things like putting presence roster displays in the messages window and displaying known groups in the ticker group subscription widget you can gain a great deal of situational awareness. I realise that there may actually be no effort available to add presence support to, say, xtickertape but if there were, even integrating a minimum implementation would make a big difference methinks. > I believe Ted doesn't think XTickertape should implement the > presence protocol, or even move away from text file > configuration. Just out of interest: is this a philosophical issue or just a lack of time needed to build GUI's? Matthew. From arnold at dstc.edu.au Fri Apr 23 01:30:48 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Apr 23 01:31:01 2004 Subject: [ticker-dev] Timeout attribute In-Reply-To: Your message of "Fri, 16 Apr 2004 11:54:38 +0930." <6949B1A32630D811B8CB00306E013ADE0A10D5@ednex502.dsto.defence.gov.au> Message-ID: <200404230630.i3N6UkYP006060@piglet.dstc.edu.au> -->"Matthew" == Phillips, Matthew writes: Matthew> We should add a note about org.tickertape.message:3000 Matthew> differences, especially the change in Timeout from minutes Matthew> to seconds. I've added the following text to the section on Timeout: Note that this value was changed to use seconds, rather than minutes, quite late in the standardisation process. To minimise the impact of this change on deployed applications, the following guidelines are provided: For any message advertising a protocol version of 3001 or greater, the value SHOULD be assumed to be in seconds. For messages with earlier versions, or that do not specify a version, Timeout values of less than 60 or equal to 1440 MAY be interpreted as a number of minutes. Similarly, implementations MAY generally refrain from sending messages with timeout values of less than a minute, and for a timeout of one minute, SHOULD use a value of 61. Does that sound ok? Matthew> * We've gone back to "Attachment"? Not that I mind, but Matthew> didn't we have an exchange which resulted in going from Matthew> Attachment to MIME-Attachment a while ago? Also, using Matthew> string disallows some MIME encodings. I'd be inclined to Matthew> allow opaque or string for this field. I have been in favour of using MIME-Attachment as a more specific name to more precisely reflect the value's semantics. It was my impression, however, that the consensus was that a better solution was to use more general naming, and rely on collective agreement on the semantics (via an ontology, data-dictionary, etc). So some time ago I'd changed the spec back to Attachment, thinking that it reflected the general mood of the community. So speak up now if you favour MIME-Attachment! Anyone? Thanks Matthew, d From arnold at dstc.edu.au Fri Apr 23 01:37:03 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Apr 23 01:37:11 2004 Subject: [ticker-dev] Latest draft (was Re: Timeout attribute) In-Reply-To: Your message of "Tue, 13 Apr 2004 12:51:50 +1000." Message-ID: <200404230637.i3N6b1YP006611@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> At the risk of pushing my luck with the Timeout attribute I'd Ian> like to see a recommendation in the draft that producers not Ian> specify arbitrary message timeouts i.e. that unless there is a Ian> specific reason that the producer doesn't believe a message Ian> will have validity after a certain time then a Timeout should Ian> not be specified. This means that interactive clients would Ian> default to having an unspecified timeout for each message. I have added the following text: Clients SHOULD NOT include a Timeout attribute in messages by default: unless the user or generating program has reason to suggest a limited validity period for the message, no Timeout need be specified. Is that ok? Anyone disagree? d From arnold at dstc.edu.au Fri Apr 23 01:38:57 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Apr 23 01:39:06 2004 Subject: [ticker-dev] Latest draft (was Re: Timeout attribute) In-Reply-To: Your message of "Tue, 13 Apr 2004 12:51:50 +1000." Message-ID: <200404230638.i3N6ctYP006766@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: Ian> Finally, on a minor note, section 11 refers to section 13 for Ian> contact details, but should refer to section 14. nice catch. fixed. thanks. d From ticker-lists at lister.dnsalias.net Fri Apr 23 01:39:28 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Fri Apr 23 01:39:17 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: <6949B1A32630D811B8CB00306E013ADE0A10EB@ednex502.dsto.defence.gov.au> Message-ID: On Fri, 23 Apr 2004, Phillips, Matthew wrote: >I hope the impression isn't that I'm doing the equivalent of what >Netscape did to HTML Definitely not. I didn't mean to imply that it was bad in any way - it's a great thing that you're "innovating" (to use a far-too-overused word) and driving your useful features back out to the rest of us through the standardisation process. I wish the clients I use supported all the features Sticker has. I agree with your statements about the value of those features, and also that Ticker users who predate Sticker tend not to appreciate them for various reasons. >> I believe Ted doesn't think XTickertape should implement the >> presence protocol, or even move away from text file >> configuration. > >Just out of interest: is this a philosophical issue or just a lack of >time needed to build GUI's? I should let Ted speak for himself, but my understanding is that it's philosophical. Ian From arnold at dstc.edu.au Fri Apr 23 01:43:30 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Apr 23 01:43:39 2004 Subject: Replaces vs. Replacement-Id (was Re: [ticker-dev] Latest draft) In-Reply-To: Your message of "Wed, 14 Apr 2004 11:35:47 +1000." Message-ID: <200404230643.i3N6hSYP007180@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: >> I think the name "Replaces" is a relic from the replace-by-id >> proposal. Ian> It does seem more appropriate for that, yes. (Which is of Ian> course why I raised it :-) >> If I was to start from scratch, I'd suggest something like >> >> Replacement-For-Message-Id Replacement-Id Ian> Would you be interested in renaming the current Replaces then? I'd be happy to see "Replaces" replaced by "Replacement-Id". Given that neither Sticker nor Aquatik appears to support replacement at all, the major impact would be on xtickertape. Ted? How do you feel about the change? Anyone else have an opinion either way? d From ticker-lists at lister.dnsalias.net Fri Apr 23 01:46:59 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Fri Apr 23 01:46:44 2004 Subject: Replaces vs. Replacement-Id (was Re: [ticker-dev] Latest draft) In-Reply-To: <200404230643.i3N6hSYP007180@piglet.dstc.edu.au> Message-ID: On Fri, 23 Apr 2004, David Arnold wrote: >I'd be happy to see "Replaces" replaced by "Replacement-Id". So Replacement-Id for replace-by-replacement-id and maybe Replaces for replace-by-message-id then? Sounds good to me. Ian From arnold at dstc.edu.au Fri Apr 23 02:03:29 2004 From: arnold at dstc.edu.au (David Arnold) Date: Fri Apr 23 02:03:39 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: Your message of "Fri, 23 Apr 2004 13:32:50 +1000." Message-ID: <200404230703.i3N73RYP008741@piglet.dstc.edu.au> -->"Ian" == Ian Lister writes: >> in considering the tradeoff between usability and efficient >> evaluation, i'm not convinced that making the router do >> >> fold-case(Group) == fold-case("MyChannelName") >> >> instead of >> >> Group == "MyChannelName" >> >> is worth the usability outcome. Ian> Probably because we attach different relative importance to Ian> usability and saving CPU cycles ;-) I think it's more a case of preferring to distribute the work, rather than centralise it. But .. it's not a great deal of work, and it's something that's pretty simple for the Elvin Router to do, so it's not a major consideration. >> i believe the fundamental problem lies in the UI where we require >> users to accurately transcribe strings. Ian> To pass the issue off to the UI would mean we would have to Ian> have made sure that we'd provided everything in the protocol Ian> that the UI would need, and that our expectations of the UI are Ian> realistic. I don't think that we've done either of these. Ian> We have a means whereby group names can be communicated using Ian> the presence protocol, assuming two users are already in the Ian> same presence group, but this effectively just pushes the Ian> problem from finding correct ticker group names to finding Ian> correct presence group names. Right. This is great for friends, but maybe not so great for friends of friends, etc. Ian> While Sticker may be a model citizen in implementing many of Ian> these new protocol features (they seem to have a tendency to go Ian> from Sticker to the protocol rather than the other way around) Which I think is an excellent model, FWIW. Ian> most of the other clients are either very slow to implement Ian> them or have no plans to implement them. For example, I believe Ian> Ted doesn't think XTickertape should implement the presence Ian> protocol, or even move away from text file Ian> configuration. I don't think either of these is a problem: if someone wanted to extend XTickertape to address an audience that wasn't happy to work that way, I suspect Ted wouldn't mind them taking a copy of the code (present legalities aside). Some people are content with having to type things in accurately; others aren't. That's ok. But ... So, what's the general opinion? Is everyone happy to move to using decompose-compat(fold-case(Group)) == decompose-compat(fold-case("MyGroup")) as the general subscription template ? d From arnold at dstc.edu.au Mon Apr 26 01:56:55 2004 From: arnold at dstc.edu.au (David Arnold) Date: Mon Apr 26 01:57:07 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: Your message of "Fri, 23 Apr 2004 14:46:35 +0930." <6949B1A32630D811B8CB00306E013ADE0A10EB@ednex502.dsto.defence.gov.au> Message-ID: <200404260656.i3Q6urYP015187@piglet.dstc.edu.au> -->"Matthew" == Phillips, Matthew writes: Matthew> I think it's possible, likely even, that some of the people Matthew> on this list who have been using ticker from The Beginning, Matthew> and now have it built into their limbic reflexes, don't Matthew> fully appreciate how much _integrated_ presence adds to the Matthew> way tickertape works. That's quite possible. I've seen integrated presence in things like AIM/iChat/GAIM (where you get "replying" status, etc) and used it a little in sticker. I also used epm for a while too. Matthew> It's not just a new feature tacked on the side: it makes a Matthew> significant difference to be able to see what channels are Matthew> being used or who's listening to a given channel, and hence Matthew> the minimum audience for a message. For me, that's not *normally* something I need to know. Sometimes it would be handy -- eliminating the "Foo, are you there?" messages -- but mostly I know who listens to what channels. One aspect of the group of people I communicate with most is that they're all online constantly, and will normally check what's happened ticker-wise while they've been away from the computer. None of this is saying it's a bad thing, just some ideas about why I haven't swapped from XTickertape to Sticker :-) Matthew> Being able to see a person is there and send them a message Matthew> directly (and being warned if they're offline or away) is Matthew> also a key new feature and used a lot here at DSTO: Matthew> probably more than 80% of the chat traffic here is Matthew> person-to-person (for reference, we have about 25-30 Matthew> regular users right now). I have some traffic that is person-to-person. It uses specific channels, but could just as easily use personal channels and out-of-group threads. But most of my traffic is shared because I find it beneficial to have other people peripherally aware of what I'm asking/saying. This extends to persistent logging as well. For example, a lot of the traffic on the "dev" channel at Mantara could easily be person-to-person, but it's handy for other people to see it a lot of the time and it means it gets logged so that it can be looked up later as well. Matthew> Other things, such as being able to see that someone is Matthew> "Replying..." allows you to stop "talking over" them or to Matthew> see that they probably saw the message you just sent them. I'm not really convinced about this, I must say. I know it's common in IM apps, but I don't normally find it that useful. Presumably its prevalence means other people do though. Matthew> By doing fairly simple things like putting presence roster Matthew> displays in the messages window and displaying known groups Matthew> in the ticker group subscription widget you can gain a Matthew> great deal of situational awareness. I think this display in Sticker in some ways *reduces* my peronsal awareness: without an explicit display, I am reliant on awareness gained implicitly, and so I am more (sub-consciously) focussed on such cues. Matthew> I realise that there may actually be no effort available to Matthew> add presence support to, say, xtickertape but if there Matthew> were, even integrating a minimum implementation would make Matthew> a big difference methinks. There are probably two aspects to this: publishing information, and display information. Personally, I'm quite content that XTickertape doesn't display presence information like Sticker does: it really doesn't fit into the way I use the interface. But I wouldn't mind if it provided such information for those who wanted to use it. d From ticker-lists at lister.dnsalias.net Tue Apr 27 00:34:53 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Apr 27 00:34:44 2004 Subject: [ticker-dev] Re: channel subscription rules In-Reply-To: <200404230703.i3N73RYP008741@piglet.dstc.edu.au> Message-ID: On Fri, 23 Apr 2004, David Arnold wrote: >I think it's more a case of preferring to distribute the work, rather >than centralise it. That seems a little antithetical to the Elvin approach of pushing the work into the network rather than leaving the edge nodes to do it :-) >But .. it's not a great deal of work, and it's something that's pretty >simple for the Elvin Router to do, so it's not a major consideration. But do you still think it's more important than the ease of use gained? > Ian> While Sticker may be a model citizen in implementing many of > Ian> these new protocol features (they seem to have a tendency to go > Ian> from Sticker to the protocol rather than the other way around) > >Which I think is an excellent model, FWIW. Indeed. I guess I didn't consider that `model citizen' might be taken to mean anything but good :-) >So, what's the general opinion? Is everyone happy to move to using > > decompose-compat(fold-case(Group)) == decompose-compat(fold-case("MyGroup")) > >as the general subscription template ? I am. It needs to be accompanied by rules about copying the value exactly when replying, though. Ian From Matthew.Phillips at dsto.defence.gov.au Wed Apr 28 20:11:25 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Wed Apr 28 20:20:57 2004 Subject: [ticker-dev] Timeout attribute Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10F7@ednex502.dsto.defence.gov.au> > I've added the following text to the section on Timeout: > > Note that this value was changed to use seconds, rather than > minutes, quite late in the standardisation process. To minimise > the impact of this change on deployed applications, the following > guidelines are provided: > > For any message advertising a protocol version of 3001 or greater, > the value SHOULD be assumed to be in seconds. > > For messages with earlier versions, or that do not specify a > version, Timeout values of less than 60 or equal to 1440 MAY be > interpreted as a number of minutes. > > Similarly, implementations MAY generally refrain from sending > messages with timeout values of less than a minute, and for a > timeout of one minute, SHOULD use a value of 61. > > Does that sound ok? Sounds great. > Matthew> * We've gone back to "Attachment"? Not that I mind, but > Matthew> didn't we have an exchange which resulted in going from > Matthew> Attachment to MIME-Attachment a while ago? Also, using > Matthew> string disallows some MIME encodings. I'd be inclined to > Matthew> allow opaque or string for this field. > > I have been in favour of using MIME-Attachment as a more specific name > to more precisely reflect the value's semantics. > > It was my impression, however, that the consensus was that a better > solution was to use more general naming, and rely on collective > agreement on the semantics (via an ontology, data-dictionary, etc). > > So some time ago I'd changed the spec back to Attachment, thinking > that it reflected the general mood of the community. > > So speak up now if you favour MIME-Attachment! Anyone? Attachment gets my vote. Matthew. From Matthew.Phillips at dsto.defence.gov.au Wed Apr 28 20:32:02 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Wed Apr 28 20:40:58 2004 Subject: [ticker-dev] Re: channel subscription rules Message-ID: <6949B1A32630D811B8CB00306E013ADE0A10F8@ednex502.dsto.defence.gov.au> > Matthew> I think it's possible, likely even, that some of the people > Matthew> on this list who have been using ticker from The Beginning, > Matthew> and now have it built into their limbic reflexes, don't > Matthew> fully appreciate how much _integrated_ presence adds to the > Matthew> way tickertape works. > > That's quite possible. > > I've seen integrated presence in things like AIM/iChat/GAIM (where you > get "replying" status, etc) and used it a little in sticker. > > I also used epm for a while too. epm is kind of a one way client: you can see information about others, but it doesn't generate much in the way of useful information ;) I remember Ian had an epm running that claimed he had been active continuously for 2 months (I think he later said he'd lost track of where it was actually running!) > Matthew> It's not just a new feature tacked on the side: it makes a > Matthew> significant difference to be able to see what channels are > Matthew> being used or who's listening to a given channel, and hence > Matthew> the minimum audience for a message. > > For me, that's not *normally* something I need to know. Sometimes it > would be handy -- eliminating the "Foo, are you there?" messages -- > but mostly I know who listens to what channels. You'd know who's *active* on a given channel, but not about lurkers (in the good sense) and people who usually are online there but aren't right now. Having visiblilty of existing channels allows newbies to get up to speed quickly. > Matthew> Being able to see a person is there and send them a message > Matthew> directly (and being warned if they're offline or away) is > Matthew> also a key new feature and used a lot here at DSTO: > Matthew> probably more than 80% of the chat traffic here is > Matthew> person-to-person (for reference, we have about 25-30 > Matthew> regular users right now). > > I have some traffic that is person-to-person. It uses specific > channels, but could just as easily use personal channels and > out-of-group threads. > > But most of my traffic is shared because I find it beneficial to have > other people peripherally aware of what I'm asking/saying. This > extends to persistent logging as well. For example, a lot of the > traffic on the "dev" channel at Mantara could easily be > person-to-person, but it's handy for other people to see it a lot of > the time and it means it gets logged so that it can be looked up later > as well. I guess this is a matter of preference, but there are times when if I didn't have the p2p option I wouldn't have posted the message at all to a shared channel because of the annoyance value involved to everyone else to whom the message might not even make sense let. > Matthew> Other things, such as being able to see that someone is > Matthew> "Replying..." allows you to stop "talking over" them or to > Matthew> see that they probably saw the message you just sent them. > > I'm not really convinced about this, I must say. I know it's common > in IM apps, but I don't normally find it that useful. Presumably its > prevalence means other people do though. The scenario where this pays off is where you post a message to a group and then see several people go to "replying" status. This means that people have (a) seen it and (b) there's some interest in what you said ;) It makes a difference to know you're not posting into a void. As a side note: I've recently added the option to generate short-lived ticker notifications for selected people when they come online, which is turning out to be an excellent way to acheive peripheral awareness. > Matthew> By doing fairly simple things like putting presence roster > Matthew> displays in the messages window and displaying known groups > Matthew> in the ticker group subscription widget you can gain a > Matthew> great deal of situational awareness. > > I think this display in Sticker in some ways *reduces* my peronsal > awareness: without an explicit display, I am reliant on awareness > gained implicitly, and so I am more (sub-consciously) focussed on such > cues. What clues? > Matthew> I realise that there may actually be no effort available to > Matthew> add presence support to, say, xtickertape but if there > Matthew> were, even integrating a minimum implementation would make > Matthew> a big difference methinks. > > There are probably two aspects to this: publishing information, and > display information. > > Personally, I'm quite content that XTickertape doesn't display > presence information like Sticker does: it really doesn't fit into the > way I use the interface. > > But I wouldn't mind if it provided such information for those who > wanted to use it. That would be great. Ticker groups and idle/active presence would be very useful. Cheers, Matt. From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 02:26:05 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 02:33:38 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E79@ednex502.dsto.defence.gov.au> Hi all, just wanting to gauge opinions as to the usefulness of deploying DSTO's web-based ticker logging app on www.tickertape.org. It was originally developed for JWID, but I've since gotten quite used to having it available here as a way to see what I might be missing out on ticker-wise. It provides an index of known ticker groups linked to a threaded list of messages for each group, usually displayed at 100 messages/page. In order to make it's presence known, the logger appears as a subscriber to each logged group via virtual presence (this also has the nice side-effect of publishing logged groups to new users using presence). It also has a "flat" view suitable for pointing a search engine at: we've sicced our SharePoint portal server on it, which turns out to be pretty nifty (and the key reason it was used in JWID). Right now I've got it set up to log all chat groups, with the exception of personal groups (ie ones with an "@" in them, slightly bogus I know) and groups ending in ".private", with the option to de-list specific groups on request. News groups aren't logged. The logger is JSP-based (it's built on the Sticker components that receive and store messages) and I don't think it would consume much in the way of resources other than a few MB of disk for the message database. Any objections, suggestions? Cheers, Matthew. From david at mantara.com Tue Jul 27 03:17:21 2004 From: david at mantara.com (David Arnold) Date: Tue Jul 27 03:18:44 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <6949B1A32630D811B8CB00306E013ADE010B4E79@ednex502.dsto.defence.gov.au> References: <6949B1A32630D811B8CB00306E013ADE010B4E79@ednex502.dsto.defence.gov.au> Message-ID: <622B1642-DFA5-11D8-9EBD-000A95EEC7C6@mantara.com> On 27/07/2004, at 5:26 PM, Phillips, Matthew wrote: > just wanting to gauge opinions as to the usefulness of deploying > DSTO's web-based ticker logging app on www.tickertape.org. It was > originally developed for JWID, but I've since gotten quite used to > having it available here as a way to see what I might be missing out > on ticker-wise. i don't have any objection to a public log of ticker messages. should we consider some means of warning people that their postings are publicly logged? > The logger is JSP-based (it's built on the Sticker components that > receive and store messages) and I don't think it would consume much in > the way of resources other than a few MB of disk for the message > database. eek. more Java madness :-) d From ticker-lists at lister.dnsalias.net Tue Jul 27 03:22:58 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Jul 27 03:23:18 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <622B1642-DFA5-11D8-9EBD-000A95EEC7C6@mantara.com> Message-ID: On Tue, 27 Jul 2004, David Arnold wrote: >should we consider some means of warning people that their postings are >publicly logged? The logger advertises itself as being subscribed to the channel via the presence protocol, which seems a reasonable way of doing it? Ian From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 03:30:40 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 03:38:37 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E7B@ednex502.dsto.defence.gov.au> > On Tue, 27 Jul 2004, David Arnold wrote: > >should we consider some means of warning people that their > postings are > >publicly logged? > > [Ian] > The logger advertises itself as being subscribed to the > channel via the presence protocol, which seems a reasonable > way of doing it? There is also an info page descrinbing the logger which has the email of the person (me) to contact to have a group excluded. In fact if you send a ticker message to the logger it will even reply with this page as a link. Nifty hey? ;) Matthew. From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 03:37:30 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 03:43:42 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E7D@ednex502.dsto.defence.gov.au> > eek. more Java madness :-) I'll pretend I didn't hear that ;) Actually, I really geek out on the fact that I can field components from a desktop app into a web app and only need to worry about the JSP hackage needed. The logger was put together with about a total of 3 days of work after some Canadian JWID guys decided it would be a cool idea to index messages - it wouldn't have happened at all if we had to build it from scratch. I also had to geek out a little more when, after I developed and tested it on Tomcat, it deployed and ran on WebSphere first go 8) Matthew. From anthony at wilkinson.name Tue Jul 27 05:42:48 2004 From: anthony at wilkinson.name (Anthony J Wilkinson) Date: Tue Jul 27 05:42:58 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: References: <622B1642-DFA5-11D8-9EBD-000A95EEC7C6@mantara.com> Message-ID: <31208.203.19.232.65.1090924968.squirrel@diadora.client.uq.net.au> Ian Lister said: > On Tue, 27 Jul 2004, David Arnold wrote: >>should we consider some means of warning people that their postings are >>publicly logged? > > The logger advertises itself as being subscribed to the channel via the > presence protocol, which seems a reasonable way of doing it? > > Ian Except for those who run clients that don't support presence or who use routers controlled by fascists who don't let presence info in or out. I'm guessing that the response to the first is that anyone using non-presence aware clients is a 733t haxor and will know all about it. No problem for me or mine because I have no intention of telling anyone about any client other than Sticker - if they want to dabble they get what they deserve. The second point is relevant to me (being just such a fascist) but I'm guessing that you are going to say "let presence in" to which I say "not until the amount of traffic drops significantly" or you might say "tough" to which I say "bugger - I'll have to document it myself internally". Anyway - just thought I'd mention it. Cheers, Anthony From ticker-lists at lister.dnsalias.net Tue Jul 27 08:26:05 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Jul 27 08:26:23 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <31208.203.19.232.65.1090924968.squirrel@diadora.client.uq.net.au> Message-ID: On Tue, 27 Jul 2004, Anthony J Wilkinson wrote: >Except for those who run clients that don't support presence or who use >routers controlled by fascists who don't let presence info in or out. Damn, and there I was trying to take the aggressive approach - forgot about those who don't move and stay on the bleeding edge of the latest and greatest standards and drafts ;-) At least we're not actually *breaking* those without presence support, they're just missing out on information there's no good way of automatically presenting to them anyway. Ian From petrilli at gmail.com Tue Jul 27 09:20:13 2004 From: petrilli at gmail.com (Christopher Petrilli) Date: Tue Jul 27 09:20:17 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: References: Message-ID: <59d991c40407270720c8ab7e7@mail.gmail.com> On Tue, 27 Jul 2004 23:26:05 +1000, Ian Lister wrote: > On Tue, 27 Jul 2004, Anthony J Wilkinson wrote: > >Except for those who run clients that don't support presence or who use > >routers controlled by fascists who don't let presence info in or out. > > Damn, and there I was trying to take the aggressive approach - forgot > about those who don't move and stay on the bleeding edge of the latest and > greatest standards and drafts ;-) > > At least we're not actually *breaking* those without presence support, > they're just missing out on information there's no good way of > automatically presenting to them anyway. If the logging app has presence support, what about having it send a private message to a user when thery join the group letting them know "Archives of this are available on the web at ....". That would both advertise the usefulness of the approach, as well as warn people. :-) As Ian pointed out, this does exclude those with presence support, but even that could be detected by keeping a list of who has been "notified" and who has posted. So that those who publish a message are sent a notice. Ideas? Chris -- | Christopher Petrilli | petrilli@gmail.com From david at mantara.com Tue Jul 27 17:01:45 2004 From: david at mantara.com (David Arnold) Date: Tue Jul 27 17:03:15 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: References: Message-ID: <8CD9C3B2-E018-11D8-9EBD-000A95EEC7C6@mantara.com> On 27/07/2004, at 6:22 PM, Ian Lister wrote: > On Tue, 27 Jul 2004, David Arnold wrote: >> should we consider some means of warning people that their postings >> are >> publicly logged? > > The logger advertises itself as being subscribed to the channel via the > presence protocol, which seems a reasonable way of doing it? yeah, true. that's probably good enough, i guess. d From david at mantara.com Tue Jul 27 17:03:54 2004 From: david at mantara.com (David Arnold) Date: Tue Jul 27 17:05:18 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <6949B1A32630D811B8CB00306E013ADE010B4E7D@ednex502.dsto.defence.gov.au> References: <6949B1A32630D811B8CB00306E013ADE010B4E7D@ednex502.dsto.defence.gov.au> Message-ID: On 27/07/2004, at 6:37 PM, Phillips, Matthew wrote: > I also had to geek out a little more when, after I developed and > tested it on Tomcat, it deployed and ran on WebSphere first go 8) you're having way too much fun. you research guys -- just playing around all day! :-) d From david at mantara.com Tue Jul 27 17:08:47 2004 From: david at mantara.com (David Arnold) Date: Tue Jul 27 17:10:12 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <31208.203.19.232.65.1090924968.squirrel@diadora.client.uq.net.au> References: <622B1642-DFA5-11D8-9EBD-000A95EEC7C6@mantara.com> <31208.203.19.232.65.1090924968.squirrel@diadora.client.uq.net.au> Message-ID: <8837CA95-E019-11D8-9EBD-000A95EEC7C6@mantara.com> On 27/07/2004, at 8:42 PM, Anthony J Wilkinson wrote: > The second point is relevant to me (being just such a fascist) but I'm > guessing that you are going to say "let presence in" to which I say > "not > until the amount of traffic drops significantly" This is a bit of a concern ... it shouldn't be so much traffic that people are forced to block it because of the volume (especially given the limited size of the current user community). How much are you seeing Anthony? And how much would be alright? d From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 20:02:14 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 20:08:45 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E87@ednex502.dsto.defence.gov.au> > [Ian] > > At least we're not actually *breaking* those without > presence support, > > they're just missing out on information there's no good way of > > automatically presenting to them anyway. > > If the logging app has presence support, what about having it > send a private message to a user when thery join the group > letting them know "Archives of this are available on the web > at ....". That would both advertise the usefulness of the > approach, as well as warn people. :-) Seems like a good idea. Unfortunately it's not a trivial thing to add, since right now the logger only emits presence info, it doesn't consume it. To implement the welcome message feature, it would have to track other's presence status and ticker group sets. It's not out of the question, since a lot of of that could be provided by the existing Sticker presence components, but since this isn't an official project any more I'd have to find some idle time to do it in. Matthew. From ticker-lists at lister.dnsalias.net Tue Jul 27 20:11:23 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Jul 27 20:11:41 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <6949B1A32630D811B8CB00306E013ADE010B4E87@ednex502.dsto.defence.gov.au> Message-ID: On Wed, 28 Jul 2004, Phillips, Matthew wrote: >Seems like a good idea. Unfortunately it's not a trivial thing to add, >since right now the logger only emits presence info, it doesn't consume >it. To implement the welcome message feature, it would have to track >other's presence status and ticker group sets. It's not out of the >question, since a lot of of that could be provided by the existing >Sticker presence components, but since this isn't an official project any >more I'd have to find some idle time to do it in. Is the source open/available? You might have yourself a volunteer, you never know ;-) Ian From anthony at wilkinson.name Tue Jul 27 20:19:14 2004 From: anthony at wilkinson.name (Anthony J Wilkinson) Date: Tue Jul 27 20:19:19 2004 Subject: [ticker-dev] Ticker logging Message-ID: <17647.203.19.232.65.1090977554.squirrel@diadora.client.uq.net.au> David Arnold said: > On 27/07/2004, at 8:42 PM, Anthony J Wilkinson wrote: > >> The second point is relevant to me (being just such a fascist) but I'm >> guessing that you are going to say "let presence in" to which I say >> "not>> until the amount of traffic drops significantly" > > This is a bit of a concern ... it shouldn't be so much traffic that > people are forced to block it because of the volume (especially given > the limited size of the current user community).> > How much are you seeing Anthony? And how much would be alright? significantly more that the amount of ticker traffic. Basically I don't want this to get to the level where people have yet another thing to complain about. Ticker and elvin (some thing to most here) have a bad reputation and I'm doing everything I can to change this. So it's not about numbers it's just about a feeling. Not very scientific but I don't plan on spending huge amounts of time on this - I've spent far too much on setting it up as it is. When I get more time I'll have another look - someone said something about the amount of presence traffic going down with later versions of Sticker or presence or something?? Cheers,Anthony From ticker-lists at lister.dnsalias.net Tue Jul 27 20:21:41 2004 From: ticker-lists at lister.dnsalias.net (Ian Lister) Date: Tue Jul 27 20:22:03 2004 Subject: [ticker-dev] Ticker logging In-Reply-To: <17647.203.19.232.65.1090977554.squirrel@diadora.client.uq.net.au> Message-ID: On Wed, 28 Jul 2004, Anthony J Wilkinson wrote: >When I get more time I'll have another look - someone said something about >the amount of presence traffic going down with later versions of Sticker >or presence or something?? Cheers,Anthony I think we worked out each new Sticker client would receive less traffic, but there would be more traffic across your federation link. Ian From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 20:39:31 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 20:43:45 2004 Subject: [Spam Detected] Re: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E89@ednex502.dsto.defence.gov.au> > On Wed, 28 Jul 2004, Anthony J Wilkinson wrote: > >When I get more time I'll have another look - someone said something > >about the amount of presence traffic going down with later > versions of > >Sticker or presence or something?? Cheers,Anthony > > I think we worked out each new Sticker client would receive > less traffic, but there would be more traffic across your > federation link. Exactly. Rolling out Sticker 3.1 should reduce the traffic significantly. Or I could turn off the "optimization" in the 3.1dev clients that's triggering this if it's turning out not to be worth it. Matthew. From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 20:36:51 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 20:43:45 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E88@ednex502.dsto.defence.gov.au> > > The second point is relevant to me (being just such a > fascist) but I'm > > guessing that you are going to say "let presence in" to which I say > > "not until the amount of traffic drops significantly" > > This is a bit of a concern ... it shouldn't be so much > traffic that people are forced to block it because of the > volume (especially given the limited size of the current user > community). If you suscribe to presence notifications it can look like a lot of traffic, especially if you hit a burst (eg when someone logs in and makes a request for a lot of groups/buddies). Plus Martin's eTiks is still responding to *every* request ') [It's made a lot messier at the moment by the issue I alluded to on ticker earlier where the Sticker 3.0 clients are erroneously counting certain update ntfns as globally visible and thus not emitting a periodic keepalive within a 5-minute window, causing the 3.1 clients (which have an optimisation of their presence subscription) to periodically re-request their info. While the de-centralised, stateless nature of the protocol is generally mostly a really good thing, this is one of those bad aspects: an implementation error in the clients is much harder to fix.] As a quick test, I just ran ec with a presence sub of "require(Presence-Protocol)" over 10 minutes, output to a file, which has come to 254KB. Assuming the textual dump from ec roughly translates to the amount of net traffic (??), that's an average of 0.42KB/sec or 35MB/day. This is a very rough estimate, but it doesn't seem ridiculously high if you've got a corporate-sized pipe? Cheers, Matthew. From Matthew.Phillips at dsto.defence.gov.au Tue Jul 27 20:50:21 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Jul 27 20:58:44 2004 Subject: [ticker-dev] Ticker logging Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4E8B@ednex502.dsto.defence.gov.au> > [Ian] > On Wed, 28 Jul 2004, Phillips, Matthew wrote: > >Seems like a good idea. Unfortunately it's not a trivial > thing to add, > >since right now the logger only emits presence info, it > doesn't consume > >it. To implement the welcome message feature, it would have to track > >other's presence status and ticker group sets. It's not out of the > >question, since a lot of of that could be provided by the existing > >Sticker presence components, but since this isn't an > official project > >any more I'd have to find some idle time to do it in. > > Is the source open/available? You might have yourself a > volunteer, you never know ;-) The source for Sticker is of course open and I think I could persuade the powers that be to open the source to the logger too. So, anyone who feels inspired, get in touch with me ;) Matthew. From Matthew.Phillips at dsto.defence.gov.au Sun Aug 1 20:42:48 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Sun Aug 1 20:49:22 2004 Subject: [ticker-dev] Aquatik ticker 3.0 support Message-ID: <6949B1A32630D811B8CB00306E013ADE010B4EDE@ednex502.dsto.defence.gov.au> Hi all, just taking up the role of protocol nazi again. Aquatik seems to be claiming it's generating v3.0 messages, but using v3.1 timeouts (in seconds) and v1.0 attachments. An example message I spotted last week is attached. It's also using int64's instead of int32's in a number of places. The main problem is the attachments though, since the v3 format tag may stop clients from looking for the v1 attachment. Cheers, Matthew. Message-Id: "3038d679a5098a1a93037fc44d7d6e9991ce3861" MIME_ARGS: "http://www.onlinestrategy.com.au/cgi-bin/blosxom.cgi/lawley/" In-Reply-To: "b5876e6b9f74cb9a7bb4f23286d0f71e619de0b9" User-Agent: "aquatik (debug) 1.4-debug" MIME_TYPE: "x-elvin/url" From: "lawless@osx" org.tickertape.message: 3000L Thread-Id: "83242b0d1398184a34ebadc639036bfb7af55b97" Timeout: 30L TIMEOUT: 30L TICKERTEXT: "PS my blog" TICKERTAPE: "Chat" Message: "PS my blog" USER: "lawless@osx" From Matthew.Phillips at dsto.defence.gov.au Sun Aug 15 22:52:11 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Sun Aug 15 22:56:08 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B5051@ednex502.dsto.defence.gov.au> Hi all, I've decided I'd like to add the ability to "invite" others to a ticker group for the next Sticker (it's about the only useful suggestion I had from JWID and I want to show willing ;) So I'm proposing a simple attachment format for ticker groups, and suggesting "application/x-elvin-tickergroup" as the MIME type. Some examples probably will get the idea across: --- Ticker-Group: 1.0 Name: ticker-dev Type: chat ---- Ticker-Group: 1.0 Name: CNN Type: news ---- Ticker-Group: 1.0 Name: Interesting Type: custom Subscription: contains (Message, "foobar") ---- You'll note the idea is to use the same "name: value" format as for keys. To spec the format a little more precisely, I'm also proposing: * UTF-8 encoding be the default * To allow either \n or \r\n as the line-delimeter * To allow empty lines and comment lines preceded by '#'. Also '\' would be an escape anywhere in a line, and at the end of a line would allow line concatenation eg: Field\:with a colon: This is a \ multiline value for "Field:with a colon" Comments, suggestions? Matthew. From david at mantara.com Sun Aug 15 23:31:20 2004 From: david at mantara.com (David Arnold) Date: Sun Aug 15 23:31:34 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Mon, 16 Aug 2004 13:22:11 +0930." <6949B1A32630D811B8CB00306E013ADE010B5051@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> So I'm proposing a simple attachment format for ticker Matthew> groups, and suggesting "application/x-elvin-tickergroup" as Matthew> the MIME type. rushing off now, but for historical interest: http://elvin.dstc.com/ticker2001/minutes/mime/mime_index.html http://elvin.dstc.com/ticker2001/minutes/mime/index.html more thoughts later, d From Matthew.Phillips at dsto.defence.gov.au Sun Aug 15 23:59:55 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Mon Aug 16 00:01:12 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B5055@ednex502.dsto.defence.gov.au> I should have remembered the legendary ticker 2001 ;) It seems like the proposed format covers most of the obvious things suggested by that session, although a default timeout might be an option we like to add? I forgot to include two things: * The subscription for "custom" group types should probably be in addition to a default sub that selects whatever the client can handle as a valid ticker/news message. * Other client-specific fields should just use the X-Blah format. This would allow exchange of extra stuff, eg colour schemes, xtickertape auto-MIME etc. Matthew. > -----Original Message----- > From: ticker-dev-bounces@tickertape.org > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of David Arnold > Sent: Monday, 16 August 2004 2:01 PM > To: ticker-dev@tickertape.org > Subject: [Spam Detected] Re: [ticker-dev] Ticker group > "invitation" attachments > > -->"Matthew" == Phillips, Matthew > writes: > > Matthew> So I'm proposing a simple attachment format for ticker > Matthew> groups, and suggesting "application/x-elvin-tickergroup" as > Matthew> the MIME type. > > rushing off now, but for historical interest: > > http://elvin.dstc.com/ticker2001/minutes/mime/mime_index.html > http://elvin.dstc.com/ticker2001/minutes/mime/index.html > > more thoughts later, > > > > > > d > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From Matthew.Phillips at dsto.defence.gov.au Tue Aug 24 20:47:43 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Aug 24 20:52:26 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B50F6@ednex502.dsto.defence.gov.au> Just to add to the buzzing of excitement that this proposal has generated, I'd like to extend it a bit to add security properties eg: Ticker-Group: 1.0 Name: Private Chat Type: chat Private-Keys: Private Chat,My Private Key Default-Secure: true Accept-Insecure: false New fields (all optional): * Private Keys: comma-separated list of private key names (do all clients have symbolic names for keys?) * Shared-Keys: Same as above for any shared keys. * Default-Secure: "true" or "false" (case insensitive) to indicate default to sending securely or not. Default is true (but obviously moot if no keys are included). * Accept-Insecure: "true" or "false" (case insensitive) to indicate whether to accept insecure messages or not. Default is true. Since I'm kind of in a hurry to get this into the imminent beta release, and there doesn't seem to be a lot of interest in this from anyone else, I'm going to go ahead and implement it if good reasons not to haven't come in before Friday. If any changes are needed, we can bump the version number and I'll support both in the full release. Just out of interest: am I the only one doing, or planning to do, any serious development in the ticker/presence area? Matthew. > -----Original Message----- > From: ticker-dev-bounces@tickertape.org > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of > Phillips, Matthew > Sent: Monday, 16 August 2004 1:22 PM > To: 'ticker-dev@tickertape.org' > Subject: [Spam Detected] [ticker-dev] Ticker group > "invitation" attachments > > Hi all, > > I've decided I'd like to add the ability to "invite" others > to a ticker group for the next Sticker (it's about the only > useful suggestion I had from JWID and I want to show willing > ;) So I'm proposing a simple attachment format for ticker > groups, and suggesting "application/x-elvin-tickergroup" as > the MIME type. Some examples probably will get the idea across: > > --- > > Ticker-Group: 1.0 > Name: ticker-dev > Type: chat > > ---- > > Ticker-Group: 1.0 > Name: CNN > Type: news > > ---- > > Ticker-Group: 1.0 > Name: Interesting > Type: custom > Subscription: contains (Message, "foobar") > > ---- > > You'll note the idea is to use the same "name: value" format > as for keys. To spec the format a little more precisely, I'm > also proposing: > > * UTF-8 encoding be the default > * To allow either \n or \r\n as the line-delimeter > * To allow empty lines and comment lines preceded by '#'. > > Also '\' would be an escape anywhere in a line, and at the > end of a line would allow line concatenation eg: > > Field\:with a colon: This is a \ > multiline value for "Field:with a colon" > > Comments, suggestions? > > Matthew. > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From david at mantara.com Tue Aug 24 22:50:59 2004 From: david at mantara.com (David Arnold) Date: Tue Aug 24 22:51:09 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Wed, 25 Aug 2004 11:17:43 +0930." <6949B1A32630D811B8CB00306E013ADE010B50F6@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> Just to add to the buzzing of excitement that this proposal Matthew> has generated It has been quiet ... is everyone asleep? :-) Matthew> I'd like to extend it a bit to add security properties eg: That's a reasonable thing. I've had a quick look at the format. Some comments below: Matthew> Ticker-Group: 1.0 Is this value a string? Or a float? We ended up using an int32 (major * 1000 + minor) for Chat messages? We also used "org.tickertape.message" to identify the protocol -- should this be "org.tickertape.group" for consistency? Matthew> Name: Private Chat Matthew> Type: chat Ok. Matthew> Private-Keys: Private Chat,My Private Key Is there some reason you'd prefer commas instead of vertical-bars as used for the other lists of strings in the Tickertape and Presence protocols? How does this work -- if you sent me this message, where would I get the key values from? If I already had them, isn't it likely that mine would have different names to yours? (ie. "My Private Key" would be a fine key name, but not so good when sent to someone else) Matthew> Default-Secure: true Matthew> Accept-Insecure: false Would it be better to make these values integers rather than strings? Matthew> Just out of interest: am I the only one doing, or planning Matthew> to do, any serious development in the ticker/presence area? Did you see Ted's recent release of xtickertape-2.0rc1 ? d From david at mantara.com Tue Aug 24 23:02:26 2004 From: david at mantara.com (David Arnold) Date: Tue Aug 24 23:02:39 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Wed, 25 Aug 2004 11:17:43 +0930." <6949B1A32630D811B8CB00306E013ADE010B50F6@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> Name: Private Chat Should this be "Group", rather than "Name" ? That's what it's called in the Tickertape Elvin messages ... d From Matthew.Phillips at dsto.defence.gov.au Tue Aug 24 23:12:56 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Aug 24 23:17:19 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B5100@ednex502.dsto.defence.gov.au> [David] > writes: > > Matthew> Name: Private Chat > > Should this be "Group", rather than "Name" ? > > That's what it's called in the Tickertape Elvin messages ... I'm thinking of the whole package/object as the group, comprised of several attributes including its name. For example the key format uses "Name:" rather than "Key:". Matthew. From Matthew.Phillips at dsto.defence.gov.au Tue Aug 24 23:10:45 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Aug 24 23:17:27 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B50FF@ednex502.dsto.defence.gov.au> [David] > Matthew> Ticker-Group: 1.0 > > Is this value a string? Or a float? > > We ended up using an int32 (major * 1000 + minor) for Chat messages? > > We also used "org.tickertape.message" to identify the > protocol -- should this be "org.tickertape.group" for consistency? > > Matthew> Name: Private Chat > Matthew> Type: chat > > Ok. > > Matthew> Private-Keys: Private Chat,My Private Key > > Is there some reason you'd prefer commas instead of > vertical-bars as used for the other lists of strings in the > Tickertape and Presence protocols? I probably should have made it clearer that I intend this as the payload of a MIME attachment rather than as a notification format. So the "tricks" we've used for version numbers and lists to make it possible to intelligently subscribe to notifications in that format have given way to what (I think) are more human-friendly. > How does this work -- if you sent me this message, where would I get > the key values from? If I already had them, isn't it likely that > mine would have different names to yours? (ie. "My Private > Key" would be a fine key name, but not so good when sent to > someone else) Yes, I agree this could be seen as slightly bogus. However, I basically intend this to be used in the scenario where I'm setting up a new secure group and email the key around (or whatever) and then send out an invitation on ticker (in the case where we already have an appropriate key, the first step can be skipped). Short of embedding the actual key in the invite, which would be pointless unless we already have a secure group to use, the use of key names is the only way I can think of (I'm assuming that using unique key names is the best way to manage otherwise anonymous chunks of data). If you don't have the key(s), then you should get warning: no biggie, you just need to do it manually. [David] > Matthew> Just out of interest: am I the only one doing, or planning > Matthew> to do, any serious development in the ticker/presence area? > > Did you see Ted's recent release of xtickertape-2.0rc1 ? I did, but I assumed this was a fairly minor bug-fix release? Not sure why I assumed that, except that I get the impression Ted's not doing much active development of xtickertape right now. Matthew. From david at mantara.com Wed Aug 25 00:07:34 2004 From: david at mantara.com (David Arnold) Date: Wed Aug 25 00:07:45 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Wed, 25 Aug 2004 13:40:45 +0930." <6949B1A32630D811B8CB00306E013ADE010B50FF@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> I probably should have made it clearer that I intend this Matthew> as the payload of a MIME attachment rather than as a Matthew> notification format. So the "tricks" we've used for version Matthew> numbers and lists to make it possible to intelligently Matthew> subscribe to notifications in that format have given way to Matthew> what (I think) are more human-friendly. Ahh, but you've stumbled on my (not-so) hidden agenda: I'd like to be able to use the same syntax (and more specifically, the same code) to send subscription events to my multiple tickertapes ... >> How does this work -- if you sent me this message, where would I >> get the key values from? If I already had them, isn't it likely >> that mine would have different names to yours? (ie. "My Private >> Key" would be a fine key name, but not so good when sent to >> someone else) Matthew> However, I basically intend this to be used in the scenario Matthew> where I'm setting up a new secure group and email the key Matthew> around (or whatever) and then send out an invitation on Matthew> ticker (in the case where we already have an appropriate Matthew> key, the first step can be skipped). If you're going to send the key around in email, you might as well attach the invitation as well -- then the receiver can "open" the attachment, which should subscribe them (probably via a confirmation dialog box). Another example would be a link on a web page -- eg. Mantara might use such a file to advertise the "elvin-support" channel. I played briefly with such a setup before the 2001 workshop, and it was very nice (if I do say so myself). I couldn't convince anyone else at the time though :-/ Matthew> Short of embedding the actual key in the invite, which Matthew> would be pointless unless we already have a secure group to Matthew> use, the use of key names is the only way I can think of Matthew> (I'm assuming that using unique key names is the best way Matthew> to manage otherwise anonymous chunks of data). Well ... maybe? If the receivers are likely to already have a copy of the key, then some sort of unique identifier is good. But "unique identifier" and "user friendly name" should probably be different things? In the case where the receiver doesn't already have the key, and the use of an existing, secure Elvin channel to deliver it doesn't exist, then you're left with other means: a PKI, HTTP(S), email, sneakernet, SMS, voice, etc. This is where Jinx tried to help -- if you can send a message, with deliver_insecure set false, and including the known public keys of all intended receivers, you can send the key inline ... I'm fairly dubious about using "David's Key" as a suitable identifier because of the potential for collisions. Also, it'd be nice to specify a file extension while we're at it, so you can get suitable icons for such files in file manager apps, etc. The "tt" prefix is kinda taken by TrueType, so "tts" seems likely to be collision-prone -- any other suggestions? >> Did you see Ted's recent release of xtickertape-2.0rc1 ? Matthew> I did, but I assumed this was a fairly minor bug-fix Matthew> release? Not sure why I assumed that, except that I get the Matthew> impression Ted's not doing much active development of Matthew> xtickertape right now. I guess it wasn't a major release, but it brought it up to spec with latest v3 rules, added the ability to reload your keys file without restarting and added the use of SIGHUP to cause a reload of all config files. Fairly major improvements albeit not especially visible ones. d From Matthew.Phillips at dsto.defence.gov.au Wed Aug 25 04:27:44 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Wed Aug 25 04:32:24 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B510C@ednex502.dsto.defence.gov.au> [David] > -->"Matthew" == Phillips, Matthew > writes: > > Matthew> I probably should have made it clearer that I intend this > Matthew> as the payload of a MIME attachment rather than as a > Matthew> notification format. So the "tricks" we've used for version > Matthew> numbers and lists to make it possible to intelligently > Matthew> subscribe to notifications in that format have given way to > Matthew> what (I think) are more human-friendly. > > Ahh, but you've stumbled on my (not-so) hidden agenda: I'd > like to be able to use the same syntax (and more > specifically, the same code) to send subscription events to > my multiple tickertapes ... Eeeek! Too complex [small popping sound as brain implodes] ;) I was kind of just seeing this as a natural complement to the key file format. > >> How does this work -- if you sent me this message, where would I > >> get the key values from? If I already had them, isn't it likely > >> that mine would have different names to yours? (ie. "My Private > >> Key" would be a fine key name, but not so good when sent to > >> someone else) > > Matthew> However, I basically intend this to be used in the scenario > Matthew> where I'm setting up a new secure group and email the key > Matthew> around (or whatever) and then send out an invitation on > Matthew> ticker (in the case where we already have an appropriate > Matthew> key, the first step can be skipped). > > If you're going to send the key around in email, you might as > well attach the invitation as well -- then the receiver can > "open" the attachment, which should subscribe them (probably > via a confirmation dialog box). Good point. Although I tend to re-use keys and so, once they're exchanged, an invitation that refers to them would still be useful. But being able to optionally embed the key(s) with the invitation would make more sense - I didn't go there because the name/value format isn't composable. Dare I mention XML? ;) > Another example would be a link on a web page -- eg. Mantara > might use such a file to advertise the "elvin-support" channel. > > I played briefly with such a setup before the 2001 workshop, > and it was very nice (if I do say so myself). I couldn't > convince anyone else at the time though :-/ > > Matthew> Short of embedding the actual key in the invite, which > Matthew> would be pointless unless we already have a secure group to > Matthew> use, the use of key names is the only way I can think of > Matthew> (I'm assuming that using unique key names is the best way > Matthew> to manage otherwise anonymous chunks of data). > > Well ... maybe? > > If the receivers are likely to already have a copy of the > key, then some sort of unique identifier is good. But > "unique identifier" and "user friendly name" should probably > be different things? Good point. An alternative would be to just treat the SHA1 of a the key as its ID? (or the key itself for shared keys). I know this isn't fullproof. > In the case where the receiver doesn't already have the key, > and the use of an existing, secure Elvin channel to deliver > it doesn't exist, then you're left with other means: a PKI, > HTTP(S), email, sneakernet, SMS, voice, etc. > > This is where Jinx tried to help -- if you can send a > message, with deliver_insecure set false, and including the > known public keys of all intended receivers, you can send the > key inline ... You can do that with Sticker too btw. > Also, it'd be nice to specify a file extension while we're at > it, so you can get suitable icons for such files in file > manager apps, etc. > The "tt" prefix is kinda taken by TrueType, so "tts" seems > likely to be collision-prone -- any other suggestions? That would make sense, but I certainly wasn't planning to actually implement anything like that :/ Managing registration of file extensions is just Too Hard (tm). For now I'm just allowing copying of key text from anywhere and allowing it to be pasted into Sticker. > >> Did you see Ted's recent release of xtickertape-2.0rc1 ? > > Matthew> I did, but I assumed this was a fairly minor bug-fix > Matthew> release? Not sure why I assumed that, except that I get the > Matthew> impression Ted's not doing much active development of > Matthew> xtickertape right now. > > I guess it wasn't a major release, but it brought it up to > spec with latest v3 rules, added the ability to reload your > keys file without restarting and added the use of SIGHUP to > cause a reload of all config files. Fairly major > improvements albeit not especially visible ones. V3 support is good. Now all we need is Aquatik to do v3 (fully ;) and we can drop the v1/v3 hybrid ticker messages. Matthew. From david at mantara.com Wed Aug 25 05:02:53 2004 From: david at mantara.com (David Arnold) Date: Wed Aug 25 05:03:08 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Wed, 25 Aug 2004 18:57:44 +0930." <6949B1A32630D811B8CB00306E013ADE010B510C@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> I was kind of just seeing this as a natural complement to Matthew> the key file format. That's a reasonable model, I reckon. But being lazy, I just figured that using ep/ec syntax, and notification-compatible naming made more things easier in future ... :-) >> If you're going to send the key around in email, you might as >> well attach the invitation as well -- then the receiver can >> "open" the attachment, which should subscribe them (probably via >> a confirmation dialog box). Matthew> Good point. Although I tend to re-use keys and so, once Matthew> they're exchanged, an invitation that refers to them would Matthew> still be useful. Yep. Matthew> But being able to optionally embed the key(s) with the Matthew> invitation would make more sense - I didn't go there Matthew> because the name/value format isn't composable. Dare I Matthew> mention XML? ;) Well, you could compose them using XML, but I think keys and groups are better as independent entities? Maybe MIME's multipart/related (RFC-2112) and CID URLs (RFC-2111) would be a better approach? This would also imply that the value of the *-Keys files would need to allow URLs. Which might be a good thing anyway. Matthew> An alternative would be to just treat the SHA1 of a the key Matthew> as its ID? (or the key itself for shared keys). Hrm. I guess that might work ... >> In the case where the receiver doesn't already have the key, and >> the use of an existing, secure Elvin channel to deliver it >> doesn't exist, then you're left with other means: a PKI, HTTP(S), >> email, sneakernet, SMS, voice, etc. >> >> This is where Jinx tried to help -- if you can send a message, >> with deliver_insecure set false, and including the known public >> keys of all intended receivers, you can send the key inline ... Matthew> You can do that with Sticker too btw. So could you safely include the keys in a ticker attachment, since you can control who sees it using their advertised key? >> Also, it'd be nice to specify a file extension while we're at it, >> so you can get suitable icons for such files in file manager >> apps, etc. The "tt" prefix is kinda taken by TrueType, so "tts" >> seems likely to be collision-prone -- any other suggestions? Matthew> That would make sense, but I certainly wasn't planning to Matthew> actually implement anything like that :/ Managing Matthew> registration of file extensions is just Too Hard (tm). For Matthew> now I'm just allowing copying of key text from anywhere and Matthew> allowing it to be pasted into Sticker. Drat ... >> I guess it wasn't a major release, but it brought it up to spec >> with latest v3 rules, added the ability to reload your keys file >> without restarting and added the use of SIGHUP to cause a reload >> of all config files. Fairly major improvements albeit not >> especially visible ones. Matthew> V3 support is good. Now all we need is Aquatik to do v3 Matthew> (fully ;) and we can drop the v1/v3 hybrid ticker messages. And all the various bots, applets, etc, that continue to use v1 format messages. But you're right -- it's a fine thing :-) d From david at mantara.com Wed Aug 25 18:23:32 2004 From: david at mantara.com (David Arnold) Date: Wed Aug 25 18:23:45 2004 Subject: [ticker-dev] new IETF presence RFCs Message-ID: fyi, some new presence RFCs from the IETF: http://www.ietf.org/rfc/rfc3861.txt http://www.ietf.org/rfc/rfc3862.txt http://www.ietf.org/rfc/rfc3863.txt d From Matthew.Phillips at dsto.defence.gov.au Thu Aug 26 00:24:16 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Aug 26 00:27:27 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B5127@ednex502.dsto.defence.gov.au> [David] > -->"Matthew" == Phillips, Matthew > writes: > > Matthew> I was kind of just seeing this as a natural complement to > Matthew> the key file format. > > That's a reasonable model, I reckon. But being lazy, I just > figured that using ep/ec syntax, and notification-compatible > naming made more things easier in future ... :-) I agree, I like the simple format. But it's easy to hit the limits. > Matthew> But being able to optionally embed the key(s) with the > Matthew> invitation would make more sense - I didn't go there > Matthew> because the name/value format isn't composable. Dare I > Matthew> mention XML? ;) > > Maybe MIME's multipart/related (RFC-2112) and CID URLs > (RFC-2111) would be a better approach? That also sounds like work, and it could be fun seeing if the MIME parser I've snaffled will deal with that ;) > Well, you could compose them using XML, but I think keys and > groups are better as independent entities? The nice thing about XML is that it allows keys and groups to be separate or embedded eg: Private Chat chat true false Private Chat shared xxxxxxxxxxxxxxxx i.e. the embedded key(s) just follow the format of a standalone key. A bit offtopic, but does anyone have any feeling as to whether the above is more "correct" XML or the following: I like the terseness of the above, but it somehow doesn't feel right ;) > >> In the case where the receiver doesn't already have the key, and > >> the use of an existing, secure Elvin channel to deliver it > >> doesn't exist, then you're left with other means: a PKI, HTTP(S), > >> email, sneakernet, SMS, voice, etc. > >> > >> This is where Jinx tried to help -- if you can send a message, > >> with deliver_insecure set false, and including the known public > >> keys of all intended receivers, you can send the key inline ... > > Matthew> You can do that with Sticker too btw. > > So could you safely include the keys in a ticker attachment, > since you can control who sees it using their advertised key? Yep. > >> I guess it wasn't a major release, but it brought it up to spec > >> with latest v3 rules, added the ability to reload your keys file > >> without restarting and added the use of SIGHUP to cause a reload > >> of all config files. Fairly major improvements albeit not > >> especially visible ones. > > Matthew> V3 support is good. Now all we need is Aquatik to do v3 > Matthew> (fully ;) and we can drop the v1/v3 hybrid ticker messages. > > And all the various bots, applets, etc, that continue to use > v1 format messages. > > But you're right -- it's a fine thing :-) Do any bots out there *listen* for v1 only? I imaging we'll have to listen for v1 forever, but at some point we can stop emitting it from user agents. Matt. From agerber at dstc.edu.au Thu Aug 26 00:40:50 2004 From: agerber at dstc.edu.au (Anna Gerber) Date: Thu Aug 26 00:40:08 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: <6949B1A32630D811B8CB00306E013ADE010B5127@ednex502.dsto.defence.gov.au> Message-ID: > A bit offtopic, but does anyone have any feeling as to whether the above > is more "correct" XML or the following: > > > > defaultSecure="true" allowInsecure="false" > access="shared" data="xxxxxxxxxxxxx" /> > > > > I like the terseness of the above, but it somehow doesn't feel right ;) Generally XML attributes tend to be used for data that doesn't change often, properties, values that don't need to be displayed in a UI, or fields that only have a single, concise, simple-typed value. (Not all of these cases apply here.) So for the above, version, name, type, defaultSecure, allowInsecure and access all make sense as attributes, while data would be better as an element. Something like the following would be considered to OK as far as XML conventions go: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Anna -------------------------------------------------------------------------- Anna Gerber agerber@dstc.edu.au CRC for Enterprise Distributed Systems Technology ph: +61 7 3365 4310 GP South, University of Queensland, 4072, Australia fax: +61 7 3365 4311 -------------------------------------------------------------------------- From Matthew.Phillips at dsto.defence.gov.au Thu Aug 26 01:26:08 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Aug 26 01:32:25 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B512D@ednex502.dsto.defence.gov.au> [Anna] > So for the above, version, name, type, defaultSecure, > allowInsecure and access all make sense as attributes, while > data would be better as an element. Something like the > following would be considered to OK as far as XML conventions go: > > > > defaultSecure="true" allowInsecure="false" > access="shared">xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Goodo. Glad my instincts for brevity aren't too far out of line with the XML universe ;) Matthew. From Matthew.Phillips at dsto.defence.gov.au Tue Aug 31 21:15:38 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Aug 31 21:25:20 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B51A3@ednex502.dsto.defence.gov.au> After a brief hiatus, here's a new (improved! now with the crunchy goodness of angle brackets!) ticker group attachment format, by example: ---- 1234567890abcdef contains (Message, "foobar") || equals (From, "frodo") ---- Note that I've just mapped the existing key name/value format into XML attribute form. Matthew. > -----Original Message----- > From: ticker-dev-bounces@tickertape.org > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of > Phillips, Matthew > Sent: Thursday, 26 August 2004 2:54 PM > To: 'ticker-dev@tickertape.org' > Subject: RE: [ticker-dev] Ticker group "invitation" attachments > > [David] > > -->"Matthew" == Phillips, Matthew > > writes: > > > > Matthew> I was kind of just seeing this as a natural complement to > > Matthew> the key file format. > > > > That's a reasonable model, I reckon. But being lazy, I > just figured > > that using ep/ec syntax, and notification-compatible naming > made more > > things easier in future ... :-) > > I agree, I like the simple format. But it's easy to hit the limits. > > > Matthew> But being able to optionally embed the key(s) with the > > Matthew> invitation would make more sense - I didn't go there > > Matthew> because the name/value format isn't composable. Dare I > > Matthew> mention XML? ;) > > > > Maybe MIME's multipart/related (RFC-2112) and CID URLs > > (RFC-2111) would be a better approach? > > That also sounds like work, and it could be fun seeing if the > MIME parser I've snaffled will deal with that ;) > > > Well, you could compose them using XML, but I think keys and groups > > are better as independent entities? > > The nice thing about XML is that it allows keys and groups to > be separate or embedded eg: > > > Private Chat > chat > true > false > > > Private Chat > shared > xxxxxxxxxxxxxxxx > > > > > i.e. the embedded key(s) just follow the format of a standalone key. > > A bit offtopic, but does anyone have any feeling as to > whether the above is more "correct" XML or the following: > > > > defaultSecure="true" allowInsecure="false" > access="shared" data="xxxxxxxxxxxxx" /> > > > > I like the terseness of the above, but it somehow doesn't > feel right ;) > > > >> In the case where the receiver doesn't already have > the key, and > > >> the use of an existing, secure Elvin channel to deliver it > > >> doesn't exist, then you're left with other means: a > PKI, HTTP(S), > > >> email, sneakernet, SMS, voice, etc. > > >> > > >> This is where Jinx tried to help -- if you can send a message, > > >> with deliver_insecure set false, and including the known public > > >> keys of all intended receivers, you can send the key inline ... > > > > Matthew> You can do that with Sticker too btw. > > > > So could you safely include the keys in a ticker > attachment, since you > > can control who sees it using their advertised key? > > Yep. > > > >> I guess it wasn't a major release, but it brought it > up to spec > > >> with latest v3 rules, added the ability to reload your > keys file > > >> without restarting and added the use of SIGHUP to > cause a reload > > >> of all config files. Fairly major improvements albeit not > > >> especially visible ones. > > > > Matthew> V3 support is good. Now all we need is Aquatik to do v3 > > Matthew> (fully ;) and we can drop the v1/v3 hybrid > ticker messages. > > > > And all the various bots, applets, etc, that continue to use > > v1 format messages. > > > > But you're right -- it's a fine thing :-) > > Do any bots out there *listen* for v1 only? I imaging we'll > have to listen for v1 forever, but at some point we can stop > emitting it from user agents. > > Matt. > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From Matthew.Phillips at dsto.defence.gov.au Thu Sep 2 22:58:39 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Sep 2 23:05:44 2004 Subject: [ticker-dev] Ticker group "invitation" attachments Message-ID: <6949B1A32630D811B8CB00306E013ADE010B51DA@ednex502.dsto.defence.gov.au> So I'm guessing (a) no one cares (fair enough ;) or (b) no one hates this idea badly enough to flame me. Either way, does anyone object to me assuming this is a reasonable proposition and writing a short document to "standardise" it on tickertape.org? Matthew. > -----Original Message----- > From: ticker-dev-bounces@tickertape.org > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of > Phillips, Matthew > Sent: Wednesday, 1 September 2004 11:46 AM > To: 'ticker-dev@tickertape.org' > Subject: RE: [ticker-dev] Ticker group "invitation" attachments > > After a brief hiatus, here's a new (improved! now with the > crunchy goodness of angle brackets!) ticker group attachment > format, by example: > > ---- > > > > > > defaultSecure="true" allowInsecure="false"> > > access="shared">1234567890abcdef > > > > > contains (Message, "foobar") || > equals (From, "frodo") > > > ---- > > Note that I've just mapped the existing key name/value format > into XML attribute form. > > Matthew. > > > -----Original Message----- > > From: ticker-dev-bounces@tickertape.org > > [mailto:ticker-dev-bounces@tickertape.org] On Behalf Of Phillips, > > Matthew > > Sent: Thursday, 26 August 2004 2:54 PM > > To: 'ticker-dev@tickertape.org' > > Subject: RE: [ticker-dev] Ticker group "invitation" attachments > > > > [David] > > > -->"Matthew" == Phillips, Matthew > > > writes: > > > > > > Matthew> I was kind of just seeing this as a natural > complement to > > > Matthew> the key file format. > > > > > > That's a reasonable model, I reckon. But being lazy, I > > just figured > > > that using ep/ec syntax, and notification-compatible naming > > made more > > > things easier in future ... :-) > > > > I agree, I like the simple format. But it's easy to hit the limits. > > > > > Matthew> But being able to optionally embed the key(s) with the > > > Matthew> invitation would make more sense - I didn't go there > > > Matthew> because the name/value format isn't composable. Dare I > > > Matthew> mention XML? ;) > > > > > > Maybe MIME's multipart/related (RFC-2112) and CID URLs > > > (RFC-2111) would be a better approach? > > > > That also sounds like work, and it could be fun seeing if the MIME > > parser I've snaffled will deal with that ;) > > > > > Well, you could compose them using XML, but I think keys > and groups > > > are better as independent entities? > > > > The nice thing about XML is that it allows keys and groups to be > > separate or embedded eg: > > > > > > Private Chat > > chat > > true > > false > > > > > > Private Chat > > shared > > xxxxxxxxxxxxxxxx > > > > > > > > > > i.e. the embedded key(s) just follow the format of a standalone key. > > > > A bit offtopic, but does anyone have any feeling as to whether the > > above is more "correct" XML or the following: > > > > > > > > > defaultSecure="true" allowInsecure="false" > > access="shared" data="xxxxxxxxxxxxx" /> > > > > > > > > I like the terseness of the above, but it somehow doesn't > feel right > > ;) > > > > > >> In the case where the receiver doesn't already have > > the key, and > > > >> the use of an existing, secure Elvin channel to deliver it > > > >> doesn't exist, then you're left with other means: a > > PKI, HTTP(S), > > > >> email, sneakernet, SMS, voice, etc. > > > >> > > > >> This is where Jinx tried to help -- if you can send > a message, > > > >> with deliver_insecure set false, and including the > known public > > > >> keys of all intended receivers, you can send the key > inline ... > > > > > > Matthew> You can do that with Sticker too btw. > > > > > > So could you safely include the keys in a ticker > > attachment, since you > > > can control who sees it using their advertised key? > > > > Yep. > > > > > >> I guess it wasn't a major release, but it brought it > > up to spec > > > >> with latest v3 rules, added the ability to reload your > > keys file > > > >> without restarting and added the use of SIGHUP to > > cause a reload > > > >> of all config files. Fairly major improvements albeit not > > > >> especially visible ones. > > > > > > Matthew> V3 support is good. Now all we need is Aquatik to do v3 > > > Matthew> (fully ;) and we can drop the v1/v3 hybrid > > ticker messages. > > > > > > And all the various bots, applets, etc, that continue to use > > > v1 format messages. > > > > > > But you're right -- it's a fine thing :-) > > > > Do any bots out there *listen* for v1 only? I imaging we'll have to > > listen for v1 forever, but at some point we can stop > emitting it from > > user agents. > > > > Matt. > > _______________________________________________ > > ticker-dev mailing list > > ticker-dev@tickertape.org > > http://www.tickertape.org/mailman/listinfo/ticker-dev > > > _______________________________________________ > ticker-dev mailing list > ticker-dev@tickertape.org > http://www.tickertape.org/mailman/listinfo/ticker-dev > From david at mantara.com Fri Sep 3 21:17:18 2004 From: david at mantara.com (David Arnold) Date: Fri Sep 3 21:17:31 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Fri, 03 Sep 2004 13:28:39 +0930." <6949B1A32630D811B8CB00306E013ADE010B51DA@ednex502.dsto.defence.gov.au> Message-ID: -->"Matthew" == Phillips, Matthew writes: Matthew> So I'm guessing (a) no one cares (fair enough ;) or (b) no Matthew> one hates this idea badly enough to flame me. Well, I'd prefer that group descriptions used the existing format for key descriptions, so there was One True Way to ship keys about, with one matching MIME type, etc. But I understand that this means more work on your MIME parser, so I can see the attraction of a simpler, all-in-one format. Matthew> Either way, does anyone object to me assuming this is a Matthew> reasonable proposition and writing a short document to Matthew> "standardise" it on tickertape.org? Documenting what Sticker does is a fine thing. What's the MIME type of this format? text/xml+foo? Does anyone understand the rules for XML-based MIME? d From matthew.phillips at dsto.defence.gov.au Sun Sep 5 20:20:07 2004 From: matthew.phillips at dsto.defence.gov.au (Matthew Phillips) Date: Sun Sep 5 20:30:59 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: References: Message-ID: <413BBB47.7030704@dsto.defence.gov.au> David Arnold wrote: >-->"Matthew" == Phillips, Matthew writes: > > Matthew> So I'm guessing (a) no one cares (fair enough ;) or (b) no > Matthew> one hates this idea badly enough to flame me. > >Well, I'd prefer that group descriptions used the existing format for >key descriptions, so there was One True Way to ship keys about, with >one matching MIME type, etc. > >But I understand that this means more work on your MIME parser, so I >can see the attraction of a simpler, all-in-one format. > > > I'm a bit conflicted about this myself, given my expressed sentiments about keeping it simple ;) However, this way has the key advantage of using a single, composable (nestable) syntax that can be accepted by a wide range of environments. Plus I see the MIME multipart approach as not being much easier in that it relies on one syntax for the payload and another (MIME multipart + inter-part references) for the composition of "nested" payloads. Also, my research into MIME parsing libraries was a bit depressing, for the Java world anyway. They all seemed to be very limited, complex and bloated or very difficult to install, or all three. XML handling seems to be fairly standard in language libraries these days and, if not, well the one I bundle in Sticker (SAX + JDOM) is about 110K of bytecode so I assume it wouldn't be too terrible to have to bundle one in other languages. You might note that, although the key format deviates from the One True Way, it does so by a direct, automatic (almost) mapping from name/value to XML attributes. So, although not ideal, there is a way to work out what the XML version of the simpler format is, and even to hack a small parser that just extracts the name="value" parts for parsing keys. > Matthew> Either way, does anyone object to me assuming this is a > Matthew> reasonable proposition and writing a short document to > Matthew> "standardise" it on tickertape.org? > >Documenting what Sticker does is a fine thing. > >What's the MIME type of this format? > I'm still suggesting "application/x-elvin-tickergroup". >text/xml+foo? Does anyone >understand the rules for XML-based MIME? > > Of that I have no idea. XHTML is text/xml+html, but tacking the "xml+" seems like a hack to me (it implies there might be other ways to represent XHTML). In this case I'm proposing a One True XML Way for the group format, so whacking an xml in there seems a bit disingenuous. Matthew. From david at mantara.com Sun Sep 5 22:44:01 2004 From: david at mantara.com (David Arnold) Date: Sun Sep 5 22:44:35 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: Your message of "Mon, 06 Sep 2004 10:50:07 +0930." <413BBB47.7030704@dsto.defence.gov.au> Message-ID: -->"Matthew" == Matthew Phillips writes: >> What's the MIME type of this format? Matthew> I'm still suggesting "application/x-elvin-tickergroup". >> text/xml+foo? Does anyone understand the rules for XML-based >> MIME? Matthew> Of that I have no idea. XHTML is text/xml+html, but tacking Matthew> the "xml+" seems like a hack to me (it implies there might Matthew> be other ways to represent XHTML). In this case I'm Matthew> proposing a One True XML Way for the group format, so Matthew> whacking an xml in there seems a bit disingenuous. A quick google found me RFC-3023 http://www.ietf.org/rfc/rfc3023.txt See especially appendix A (and A.15) for a discussion of the rationale for the use of +xml d From matthew.phillips at dsto.defence.gov.au Mon Sep 6 00:47:19 2004 From: matthew.phillips at dsto.defence.gov.au (Matthew Phillips) Date: Mon Sep 6 00:50:56 2004 Subject: [ticker-dev] Ticker group "invitation" attachments In-Reply-To: References: Message-ID: <413BF9E7.7080204@dsto.defence.gov.au> David Arnold wrote: >-->"Matthew" == Matthew Phillips writes: > > >> What's the MIME type of this format? > > Matthew> I'm still suggesting "application/x-elvin-tickergroup". > > >> text/xml+foo? Does anyone understand the rules for XML-based > >> MIME? > > Matthew> Of that I have no idea. XHTML is text/xml+html, but tacking > Matthew> the "xml+" seems like a hack to me (it implies there might > Matthew> be other ways to represent XHTML). In this case I'm > Matthew> proposing a One True XML Way for the group format, so > Matthew> whacking an xml in there seems a bit disingenuous. > >A quick google found me RFC-3023 > > http://www.ietf.org/rfc/rfc3023.txt > >See especially appendix A (and A.15) for a discussion of the rationale >for the use of +xml > > Thanks for the reference. It's quite a tome - glad I don't have to think through all that guff ;) I think I understand the rationale behind +xml, but it does seem a little esoteric and, since I've cheekily gone ahead and implemented this in Sticker 3.1 beta 1 already, my natural instinct is to leave off the +xml ;) I know I'm doing a Netscape here, but I really wanted to get the invite feature out to demonstrate to the real customers. Matt. From david at mantara.com Wed Sep 8 16:43:10 2004 From: david at mantara.com (David Arnold) Date: Wed Sep 8 16:43:24 2004 Subject: [ticker-dev] IETF IM and Presence group concludes its work Message-ID: ------- Forwarded Message To: IETF-announce@ietf.org Subject: WG Action: Conclusion of Instant Messaging and Presence Protocol From: The IESG Date: Wed, 08 Sep 2004 16:10:07 -0400 The Instant Messaging and Presence Protocol (impp) WG in the Applications Area has concluded. The IESG contact persons are Ted Hardie and Scott Hollenbeck. The mailing list will remain active. +++ With the publication of RFCs 3859, 3860, 3861 3862, and 3863, the Instant Messaging and Presence Protocol working group has concluded. The group's work in the area of presence data formats and interoperable instant message formats has seen deployment both in SIMPLE-based and XMPP-based instant messaging systems and is the basis for additional work in the GEOPRIV working group. The mailing list will remain open for discussion. The IESG contact persons are Ted Hardie and Scott Hollenbeck. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ------- End of Forwarded Message From anthony at wilkinson.name Thu Sep 23 05:41:35 2004 From: anthony at wilkinson.name (Anthony J Wilkinson) Date: Thu Sep 23 05:41:45 2004 Subject: [ticker-dev] broken links at tickertape.org Message-ID: <48001.203.19.232.170.1095936095.squirrel@diadora.client.uq.net.au> http://www.tickertape.org/projects/tick/index.html all download links are broken. http://www.tickertape.org/projects/cvs2ticker/index.html download links missing the cvs2web link is broken the Python SDK links point to the mantara home page. http://www.tickertape.org/projects/python-tickertape/index.html all download links are broken (but with a nicer error message?) Python SDK is pointing at mantara/products http://www.tickertape.org/projects/scoop/index.html SHA-1 and FAQ links are broken download links missing http://www.tickertape.org/projects/xtickertape/index.html download link broken I actually just went in to have a look at tick then thought I'd try cvs2web and figured I might as well check the rest while I was there. Cheers, Anthony From Matthew.Phillips at dsto.defence.gov.au Thu Sep 23 19:28:43 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Thu Sep 23 19:33:09 2004 Subject: [ticker-dev] broken links at tickertape.org Message-ID: <6949B1A32630D811B8CB00306E013ADE010B533D@ednex502.dsto.defence.gov.au> > http://www.tickertape.org/projects/tick/index.html > all download links are broken. Yes, that's been the case since day 1. Not sure who's responsible for tick? > http://www.tickertape.org/projects/cvs2ticker/index.html > download links missing > the cvs2web link is broken > the Python SDK links point to the mantara home page. I guess this is for the Mantara guys. > http://www.tickertape.org/projects/scoop/index.html > SHA-1 and FAQ links are broken > download links missing Ditto. > http://www.tickertape.org/projects/xtickertape/index.html > download link broken Hmm, that was working earlier. Fixed now. Matthew. From Matthew.Phillips at dsto.defence.gov.au Fri Sep 24 01:18:39 2004 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Fri Sep 24 01:23:15 2004 Subject: [ticker-dev] Ticker group format document Message-ID: <6949B1A32630D811B8CB00306E013ADE010B5358@ednex502.dsto.defence.gov.au> Hi all, I've put together a short technical note describing the proposed ticker group exchange format I was meandering on about earlier. Comments, etc welcome. Although posting this on a Friday afternoon may not be the best plan if I want anyone to actually read it ;) Matthew. -------------- next part -------------- ---------------------------------------------------------------------- Elvin Ticker Group Subscription Format ---------------------------------------------------------------------- Purpose of This Document ---------------------------------------------------------------------- This document provides a brief description of the proposed format for exchanging ticker group subscriptions between tickertape messaging clients. The format is designed to allow interchange of group subscriptions amongst clients, either via ticker attachments or other textual means such as clipboard copy and paste. The format encodes not only instructions for subscribing to the content, but also any required security constraints. Overview ---------------------------------------------------------------------- A ticker group subscription is described by a "group" XML element. Three sub-types of group are defined: "chat", "news" and "custom". The first two correspond to the two major ticker message formats: inter-person chat (ticker v1.0/v3.0) and news (NNTP or web news). The "custom" type can select from news and/or chat channels and is specified via an Elvin subscription expression. The subscription will be appended with (using "&&") a expression that ensures selection of valid chat or news messages (from the client's point of view), so the subscription may be thought of as a sub-selection from all news and/or chat messages. MIME type ---------------------------------------------------------------------- The proposed MIME type for ticker groups is: application/x-elvin-tickergroup Examples ---------------------------------------------------------------------- A "chat" format group named "Babble" -------------------------------------------------------------------- A "news" format group named "CNN" -------------------------------------------------------------------- A "chat" format group called "Private Chat" with security attributes 65445e420820795b54700d6158772f0650401854 -------------------------------------------------------------------- A custom group contains (Message, "foobar") || equals (From, "frodo") Details ---------------------------------------------------------------------- A group element has three required attributes: version: The group format version. Currently must equal "1.0". name: The group's channel name. type: One of "chat", "news" or "custom". Optional security attributes: defaultSecure: Boolean ("true" or "false"). If true, the client should default to sending securely. allowInsecure: Allow send/receipt of insecure messages. If false, the client should never accept or display a message that wasn't received securely. Security keys: A group may have an optional "keys" element containing one or more XML "key" elements. These specify security keys to be associated with the group and used to restrict receivership of messages. While there is already an agreed specification for exchanging Elvin security keys, this format is not amenable to nesting within XML. However, the XML key format proposed here is a straighforward translation of existing format into XML representation. For example, a key in the current format might look like: Version: 1.0 Name: Shhhh Access: Private Key: 65445e420820795b54700d6158772f0650401854 The XML representation of this is: 65445e420820795b54700d6158772f0650401854 An example group using this key: 65445e420820795b54700d6158772f0650401854 Notes ---------------------------------------------------------------------- * Extended attributes. Clients should attach any client-specific extended information they wish to add using the "x-" naming scheme commonly used in other formats of this type. For example: * Embedded key security. This format allows private keys to be embedded in group subscriptions, which is something that the user may not realise. Clients should take steps to warn the user before sending a group with embedded private keys across an insecure channel. * Character encoding. If the character encoding differs from the assumed default of UTF-8, it should be specified using an XML header plus an explicit encoding, eg: * User interface terminology. It is suggested that clients sending ticker group subscriptions encoded in this way present the action to the user as "Send an invitation to the group". Importing the attachment would be likewise termed "Accepting the invitation". Author ---------------------------------------------------------------------- This document was written by Matthew Phillips . Last modified on 24 Sep 2004.