From Matthew.Phillips at dsto.defence.gov.au Fri Jan 4 15:37:53 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:41 2003 Subject: Java presence client update Message-ID: <8FCECF5E61F0D511946000306E0189F812E41D@ednex504.dsto.defence.gov.au> Hi all, I've used some of the time over the last few days (while no one's been looking too closely at what I'm working on ;) to beef up the Java presence implementation. The updates are mainly extensions to the UI components (you can now add particular users as well as groups to presence "contacts", change your custom properties, etc) but there are a few fixes and tweaks to the backend components also. I've put an updated JAR at ftp://203.5.217.35/pub/presence.jar, which will also run as standalone client as before. I've also integrated these components into a (pre alpha) version of Sticker and am hoping to do a 2.1.0 release in the near future. Cheers, Matthew. From arnold at dstc.monash.edu.au Tue Jan 15 09:00:39 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: ietf common presence & IM message format Message-ID: <200201142300.g0EN0Uk03242@xevious.dstc.monash.edu.au> fyi, this is the announcement of the latest draft of the IETF IMPP working group's message format speccification. ------- Forwarded Message Date: Fri, 11 Jan 2002 08:56:26 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-impp-cpim-msgfmt-05.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: impp@iastate.edu A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Instant Messaging and Presence Protocol Working Group of the IETF. Title : Common Presence and Instant Messaging Message Format Author(s) : D. Atkins, G. Klyne Filename : draft-ietf-impp-cpim-msgfmt-05.txt Pages : 30 Date : 10-Jan-02 This memo defines the mime type 'message/cpim', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-impp-cpim-msgfmt-05.txt From arnold at dstc.monash.edu.au Tue Jan 15 09:01:52 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: ietf message threading and topic extensions Message-ID: <200201142301.g0EN1hk03255@xevious.dstc.monash.edu.au> also fyi, ------- Forwarded Message Date: Fri, 11 Jan 2002 08:55:45 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-koskelainen-imtpext-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : MTP Extensions for Message Threading and Message Identification Author(s) : P. Koskelainen Filename : draft-koskelainen-imtpext-00.txt Pages : Date : 10-Jan-02 The IMTP specification defines a session-based IM transport as well as the message format for it. However, it does not support message threads or discussion topics which are useful in applications such as multi-party chat. This document defines extensions to IMTP which allow applications to utilize threads and sub-threads within an IMTP message session. Also, the extensions enable message identification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-koskelainen-imtpext-00.txt From arnold at dstc.monash.edu.au Tue Jan 15 09:04:15 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: ietf IM to SMS mapping proposal Message-ID: <200201142304.g0EN47k03276@xevious.dstc.monash.edu.au> and another ... ------- Forwarded Message Date: Fri, 11 Jan 2002 08:55:08 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-khartabil-cpim-ucp-mapping-00.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CPIM to UCP/EMI Mapping Author(s) : H. Khartabil Filename : draft-khartabil-cpim-ucp-mapping-00.txt Pages : 6 Date : 10-Jan-02 Messaging is the fastest growing means of communication in the world. Mobile telephony and SMS have also been growing at an enormous rate, eventually bound to edge out traditional telephony systems in volumes and importance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-khartabil-cpim-ucp-mapping-00.txt From Matthew.Phillips at dsto.defence.gov.au Tue Jan 22 11:19:56 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:41 2003 Subject: Java presence client updated Message-ID: <8FCECF5E61F0D511946000306E0189F812E472@ednex504.dsto.defence.gov.au> Hi all, just a quick note to say that the Java presence client at ftp://203.5.217.35/pub/sticker/presence.jar has been updated to include what will probably be the final implementation of the Java presence components before I release them as part of Sticker 2.1. There is also a (currently unreleased) beta of Sticker 2.1 if anyone is interested. Cheers, Matthew. From Matthew.Phillips at dsto.defence.gov.au Mon Feb 4 14:11:17 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:41 2003 Subject: Presence protocol - final version Message-ID: <8FCECF5E61F0D511946000306E0189F812E49D@ednex504.dsto.defence.gov.au> Hi all, if everyone is reasonably happy with the current presence spec (0.4.1), can I suggest we finalize a 1.0 version? David, others: can you think of any boilerplate text or otherwise that we should add to the document before release? Cheers, Matthew. From arnold at dstc.monash.edu.au Sat Apr 6 13:01:34 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: presence protocol publication Message-ID: <200204060256.g362umk23474@xevious.dstc.monash.edu.au> Matthew (and others), i'd like to have a home on the web for the presence protocol specification. i'm not sure where this should be: i'm happy to provide hosting at DSTC/Elvin, but if we'd prefer somewhere else, that's fine too. i (personally) own both elvin.org and tickertape.org, either of which might be suitable locations. neither are currently hosted, but i expect at least elvin.org to be up within a month. to repeat Matthew's question from Feb 4th -- are there any outstanding issues with 0.4.1? http://elvin.dstc.com/ListArchive/ticker-dev/archive/2001/12/msg00004.html d ps. ticker-v3 draft coming later today ;-) From arnold at dstc.monash.edu.au Sat Apr 6 13:12:22 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: Updates (was: Re: [ticker-dev] Presence specification draft 0.4.1) In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690AD1FEC2@xch-bne-01.bal.bna.boeing.com> Message-ID: <200204060307.g3637ak23502@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: Martin> In the ticker spec, the "REPLACEMENT" field indicates that Martin> the entire contents of a notification should be replaced, or Martin> the original notification is actually replaced by the new Martin> one, whichever way the result is the same the remaining Martin> notification ends up representing whatever notification that Martin> most recently had a replacement id that matched it To that Martin> end it is conceivable that the replacement function could be Martin> extended to perform an update, updating only existing Martin> fields. Martin> So I propose that it may be useful to add an 'UPDATES' field Martin> to the tickertape protocol to not replace a notification but Martin> to update it with only the changed/supplied fields. the benefit of REPLACEMENT is that if you don't have a copy of the original message, you can still display the new message with no loss of functionality. for this reason, i prefer the current mechanism. d From arnold at dstc.monash.edu.au Sat Apr 6 15:27:55 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: ticker-3.0 spec Message-ID: <200204060523.g365N8k23891@xevious.dstc.monash.edu.au> i've placed the first draft of the Tickertape v3 specification on DSTC's FTP site for your comments. ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-00.txt in general, this draft reflects the discussion from the ticker workshop last year, plus commentary from me, and some proposals in areas where we hadn't reached consensus. there are several areas that i would like to see clarified before final publication: 1. security i'd prefer that we specified a mechanism for secure chat. i'm happy to leave key exchange out. i think there are two competing proposals now (aquatik and jinx?) 2. Distribution Matthew and Martin are keen to have this feature, possibly with standardised semantics for its values. 3. Replaces this was contentious at the workshop. i've adopted the mechanism that uses the Message-Id, and thus allows arbitrary replacement. this is *less* secure that the current mechanism ... 4. there is currently very little explanatory or motivational text supporting the raw protocol description. there probably should be, and it should possibly reference the requirements from rfc2779. any comments on these issues, or any other aspect of the spec, would be very welcome ... procedurally, i plan to hash out the remaining issues in this group, and then publish a final -00 draft via the IETF RFC Editor as an Internet Draft. after incorporation of any feedback from that, i'll submit the revised -01 (or later) draft for publication as an Informational RFC. any comments or suggestions about this proposed process are also very welcome ... thanks, d From julian at dstc.monash.edu.au Mon Apr 8 09:39:21 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec In-Reply-To: <200204060523.g365N8k23891@xevious.dstc.monash.edu.au> Message-ID: <200204072334.g37NYLk28953@xevious.dstc.monash.edu.au> David Arnold wrote: > 1. security > > i'd prefer that we specified a mechanism for secure chat. i'm > happy to leave key exchange out. i think there are two competing > proposals now (aquatik and jinx?) I think this is the only sane option; i'm happy to write up the current jinx security implemenation, which has had one minor revision since ticker'01. key exchange is not important, IMO? -J From ilister at dstc.edu.au Mon Apr 8 09:50:38 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec In-Reply-To: <200204060523.g365N8k23891@xevious.dstc.monash.edu.au> Message-ID: On Sat, 6 Apr 2002, David Arnold wrote: > i'd prefer that we specified a mechanism for secure chat. i'm > happy to leave key exchange out. i think there are two competing > proposals now (aquatik and jinx?) I think Jinx now uses more or less identical logic to psst and the patches to XTickertape (bug #515). This can support keys used in any number of ways (e.g. per-user, per-channel, per-orgunit, etc), which is a superset of Aquatik's per-channel keys. I've been slack recently but I intend to renew pressure on Michael to adopt the more flexible logic, unless anybody can see any problems with it. Ian From arnold at dstc.monash.edu.au Mon Apr 8 09:55:24 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec In-Reply-To: Message-ID: <200204072350.g37NoOk29026@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> On Sat, 6 Apr 2002, David Arnold wrote: >> i'd prefer that we specified a mechanism for secure chat. i'm >> happy to leave key exchange out. i think there are two competing >> proposals now (aquatik and jinx?) Ian> I think Jinx now uses more or less identical logic to psst and Ian> the patches to XTickertape (bug #515). This can support keys Ian> used in any number of ways (e.g. per-user, per-channel, Ian> per-orgunit, etc), which is a superset of Aquatik's per-channel Ian> keys. perhaps you could write a short doc explaining how this model works? d From arnold at dstc.monash.edu.au Mon Apr 8 10:10:15 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec In-Reply-To: <200204072334.g37NYLk28953@xevious.dstc.monash.edu.au> Message-ID: <200204080005.g3805Fk29171@xevious.dstc.monash.edu.au> -->"Julian" == Julian Boot writes: >> i'd prefer that we specified a mechanism for secure chat. i'm >> happy to leave key exchange out. i think there are two competing >> proposals now (aquatik and jinx?) Julian> I think this is the only sane option; i'm happy to write up Julian> the current jinx security implemenation, which has had one Julian> minor revision since ticker'01. that'd be a fine thing. perhaps coordinate this with Ian's description of pssssssst and his hacks to xticker? Julian> key exchange is not important, IMO? well, not *as* important anyway, d From arnold at dstc.monash.edu.au Tue Apr 9 10:08:59 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD95D3B@XCH-BNE-01> Message-ID: <200204090003.g3903pk05639@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: Martin> What was the justification behind allowing any abitory Martin> individual or elvin producer to maliciously modify say, my Martin> stock price notifications the current replacement mechanism requires that the original message include the REPLACEMENT field to enable subsequent messages to overwrite it. this provides a level of security, at the cost of requiring an additional field in messages able to be replaced. Martin> Under the current implementation it is still possible to Martin> spoof a notification, but ONLY if it had a replacement field Martin> in the the first/original notif I see this as kind of Martin> protecting the common tickertape notifications. agreed. Martin> So please, dont allow any notification to be clobbered by Martin> replacement. would anyone like to speak in favour of allowing replacement by Message-Id? Martin> In fact I'd prefer that the replacement option to be key Martin> based, so that only the bona fide originator of a Martin> notification has the right to recall or change the notif. using keys could ensure that the replacement message was authentic, but this is separate from the replacement mechanism itself, i think? d From ilister at dstc.edu.au Tue Apr 9 10:23:36 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID In-Reply-To: <200204090003.g3903pk05639@xevious.dstc.monash.edu.au> Message-ID: On Tue, 9 Apr 2002, David Arnold wrote: > Martin> In fact I'd prefer that the replacement option to be key > Martin> based, so that only the bona fide originator of a > Martin> notification has the right to recall or change the notif. > >using keys could ensure that the replacement message was authentic, >but this is separate from the replacement mechanism itself, i think? I don't think the key model is suitable for doing this. (Read: I can't think how you'd do this without some very bad tradeoff, and even then only really by putting stuff in the notification too). That said, keys are in the right direction if you want to do this securely. The problem is that you need to verify that the sender of the two messages has the same identity, which points towards sending a public key as part of the first message and a signature with the same key as part of the second message. I can't see people implementing this any time soon :-) Ian From Martin.Wanicki at Australia.Boeing.com Tue Apr 9 10:28:32 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ??) Message-ID: <21BEC9503B89D111A8F700805FE6A3690BD95D7B@XCH-BNE-01> > Martin> In fact I'd prefer that the replacement option to be key > Martin> based, so that only the bona fide originator of a > Martin> notification has the right to recall or change the notif. > d >using keys could ensure that the replacement message was authentic, d >but this is separate from the replacement mechanism itself, i think? Yeah, I agree, although if a notif could be *keyed with the plaintext of the replacement id hash it would work, but then I know three fifths of feck-all about security and keys :-( *Keyed : Its my understanding that keys are not a client readable part of a notification and I'm not familiar enough with the api to know if there is a way to throw a key at a routine to check if the notif has this key Basically i was thinking along the lines of a digital signature. the signatures should match before replacement is done. I really dont know how to solve this but I know i would prefer it to be secure. What i did in eTiks that started out as an exercise in keeping the message thread and scroller quiet if I get 300 of the same notifs ended up with me indicating in my message thread how many times a notif hase been replaced or how many times a duplicate has been received. There is an audit trail associated with this showing the plaintext of each and every notif and the subscription text that caused the client to receive it. If a duplicate is ever received on the same sub, I can safely assume the second or subsequent ones are bogus, and I can check the contents to see the diffs. With replacement, I keep the same history, so I can see what was replaced by what. Over to y'all regs' Martin From arnold at dstc.monash.edu.au Tue Apr 9 10:33:51 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID In-Reply-To: Message-ID: <200204090028.g390Shk05807@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: >> using keys could ensure that the replacement message was >> authentic, but this is separate from the replacement mechanism >> itself, i think? Ian> I don't think the key model is suitable for doing this. (Read: Ian> I can't think how you'd do this without some very bad tradeoff, Ian> and even then only really by putting stuff in the notification Ian> too). what i meant, and i'm not sure from you mail whether you disagree, was: a) replacement and use of keys is orthogonal. b) if you choose to use keys, you can be as confident of the authenticity of a replacement message as you can of the authenticity of the original message. i was not proposing any new keying mechanism. Ian> The problem is that you need to verify that the sender of the Ian> two messages has the same identity i don't believe that's necessarily true. you *might* care about the sender's identity, but i think having the same level of confidence in the authenicity of the messages (regardless of the sender's identity or senders' identities) would normally be sufficient. Ian> sending a public key as part of the first message and a Ian> signature with the same key as part of the second message. I Ian> can't see people implementing this any time soon :-) me either. i can't see most people caring enough. d From arnold at dstc.monash.edu.au Tue Apr 9 10:55:49 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD95D7B@XCH-BNE-01> Message-ID: <200204090050.g390ofk05899@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: Martin> In fact I'd prefer that the replacement option to be key Martin> based, so that only the bona fide originator of a Martin> notification has the right to recall or change the notif. oh well. there goes my theory that most people won't care ;-) Martin> Yeah, I agree, although if a notif could be *keyed with the Martin> plaintext of the replacement id hash it would work, but then Martin> I know three fifths of feck-all about security and keys :-( i played, once, with using this kind of mechanism. it's actually not dissimilar to the Bell Labs S/Key protocol. 1. sender picks the plaintext 2. sender picks how many times it want to replace the message (** this is the bad bit **) 3. sender hashes the plaintext, and then hashes the result, and that result, etc, N times (from step 2). 4. for the first message, use the final hash and then work backwards through previous hashes. this works because the hash function is one-way, so having seen a message, a receiver cannot derive the hash of its replacement, but when it gets the replacement, if its REPLACEMENT field hashes to the REPLACEMENT of the previous message, it's legitimate. the big limitation is that the sender need to know up front how many times you want to do this. i couldn't figure out a way to do an in-band rekey over a federation -- a man-in-the-middle attacker could race the legitimate re-key packet with a malicious re-key packet, and since we don't guarantee total ordering, the nastygram could win :-( Martin> *Keyed : Its my understanding that keys are not a client Martin> readable part of a notification and I'm not familiar enough Martin> with the api to know if there is a way to throw a key at a Martin> routine to check if the notif has this key keys are not delivered to the client, so you can only check them using a subscription. Martin> Basically i was thinking along the lines of a digital Martin> signature. the signatures should match before replacement is Martin> done. but if i can receive the first signature, then i can simply dump those bytes into a bogus message. you need to have some content to sign which varies in a way which only the sender can predict, and the receiver can verify in-band. of course, if you're prepared to do an out-of-band signature verification, then the problem evaporates. you simply sign all messages. Martin> I really dont know how to solve this but I know i would Martin> prefer it to be secure. there's no such thing as "secure", only degrees of security ;-) if you trust the first message, why would you not trust a replacement with equivalent "credentials" ? d From ilister at dstc.edu.au Tue Apr 9 11:00:17 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:41 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID In-Reply-To: <200204090028.g390Shk05807@xevious.dstc.monash.edu.au> Message-ID: On Tue, 9 Apr 2002, David Arnold wrote: >what i meant, and i'm not sure from you mail whether you disagree, >was: > >a) replacement and use of keys is orthogonal. > >b) if you choose to use keys, you can be as confident of the > authenticity of a replacement message as you can of the > authenticity of the original message. Yes, that is true. In many ways you are right, but without replacement you don't have easy access to the ability to effectively suppress particular messages, which does make it a bit more of an issue than just trusting the authenticity of individual messages. It also requires clients to keep track of which subscriptions particular messages came in on, and to only accept replacements on those same subscriptions. Not a particularly significant issue I guess, just a minor complication. Ian From julian at dstc.monash.edu.au Tue Apr 9 11:11:53 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID In-Reply-To: Message-ID: <200204090106.g3916jk06004@xevious.dstc.monash.edu.au> Ian Lister wrote: > It also requires clients to keep track of which subscriptions particular > messages came in on, and to only accept replacements on those same > subscriptions. Not a particularly significant issue I guess, just a minor > complication. well, in Java, Notification.getSource() returns the subscription, for just this purpose. combined with the ability to check if a notification was secure, I don't see it as overly onerous for the developer to use keys to manage authenticated replacements. -J From ilister at dstc.edu.au Tue Apr 9 11:21:12 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ??) In-Reply-To: <200204090050.g390ofk05899@xevious.dstc.monash.edu.au> Message-ID: On Tue, 9 Apr 2002, David Arnold wrote: >i couldn't figure out a way to do an in-band rekey over a federation >-- a man-in-the-middle attacker could race the legitimate re-key >packet with a malicious re-key packet, and since we don't guarantee >total ordering, the nastygram could win :-( What's the problem with rekeying? As long as you have one key left (the original seed or its first generation) you can send a verifiable new key, no? There is of course a problem if you miss any notifications... > Martin> Basically i was thinking along the lines of a digital > Martin> signature. the signatures should match before replacement is > Martin> done. > >but if i can receive the first signature, then i can simply dump those >bytes into a bogus message. you need to have some content to sign >which varies in a way which only the sender can predict, and the >receiver can verify in-band. > >of course, if you're prepared to do an out-of-band signature >verification, then the problem evaporates. you simply sign all >messages. You don't need to do it out of band. You just send your public key with your messages and consumers can verify that subsequent messages were signed by an entity holding the same private key as that which signed the first message. >if you trust the first message, why would you not trust a replacement >with equivalent "credentials" ? I may be happy to receive it, but not necessarily for it to destroy or cause another message to be obscured. Ian From lawley at dstc.edu.au Tue Apr 9 11:26:08 2002 From: lawley at dstc.edu.au (Michael Lawley) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: <200204090050.g390ofk05899@xevious.dstc.monash.edu.au> Message-ID: <200204090126.g391Q8P05528@piglet.dstc.edu.au> Oops, just realised I replied only to David and not to ticker-dev. Here it is again... David Arnold wrote: > -->"Martin" == Wanicki, Martin writes: > Martin>In fact I'd prefer that the replacement option to be key > Martin>based, so that only the bona fide originator of a > Martin>notification has the right to recall or change the notif. > i played, once, with using this kind of mechanism. it's actually not > dissimilar to the Bell Labs S/Key protocol. > 1. sender picks the plaintext > 2. sender picks how many times it want to replace the message > (** this is the bad bit **) > 3. sender hashes the plaintext, and then hashes the result, and that > result, etc, N times (from step 2). > 4. for the first message, use the final hash and then work > backwards through previous hashes. > this works because the hash function is one-way, so having seen a > message, a receiver cannot derive the hash of its replacement, but > when it gets the replacement, if its REPLACEMENT field hashes to the > REPLACEMENT of the previous message, it's legitimate. > the big limitation is that the sender need to know up front how many > times you want to do this. If you separate the REPLACEMENT field as the key for which message to replace from the REPLACEMENT_HASH field, then you only ever need to do one-step replacement so N=1 and it's "easy". So, the process is now, choose a UUID for REPLACEMENT. Choose a plaintext and hash it, send the hash as REPLACEMENT_HASH. To replace this message, send a message with REPLACEMENT = UUID from before, REPLACEMENT_PLAIN = plaintext from before, and REPLACEMENT_HASH = a hash(new plaintext) (Actually, UUID could just be hash(plaintext), but keeping it constant should make it easier on the ticker client.) |v| "analog - the new digital" -- Michael Lawley, http://purl.org/NET/lawley Scientician. From julian at dstc.monash.edu.au Tue Apr 9 11:35:41 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: Message-ID: <200204090130.g391UXk06209@xevious.dstc.monash.edu.au> Ian Lister wrote: > >if you trust the first message, why would you not trust a replacement > >with equivalent "credentials" ? > > I may be happy to receive it, but not necessarily for it to destroy or > cause another message to be obscured. this distinction seems completely arbitary. you *could* behave like that, but you have not suggested *why* anyone would. -J From arnold at dstc.monash.edu.au Tue Apr 9 11:44:45 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: Message-ID: <200204090139.g391dak06301@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> What's the problem with rekeying? As long as you have one key Ian> left (the original seed or its first generation) you can send a Ian> verifiable new key, no? you can send a new key in a message "authenticated" by a key from the previous sequence. there are two possible attacks that i can think of: single server and federated servers. across a federation, it's easy: the malicious client attaches to the sender's server and to the receiver's server, short-circuiting the federation link (or links). the attacker receives the re-key message, and replaces the legitimate new-sequence key with its own, and injects that message into the receiver's server faster than it traverses the federation. within a single server, a lot depends upon the order of delivery, size of queues, etc, but essentially the same attack is *possible*, although unlikely to succeed. Ian> There is of course a problem if you miss any notifications... yep. although you do *notice* the loss ;-) Ian> You don't need to do it out of band. You just send your public Ian> key with your messages and consumers can verify that subsequent Ian> messages were signed by an entity holding the same private key Ian> as that which signed the first message. does this actually get you any greater confidence than using a producer-scheme key? in both cases, all it proves is that the message sender(s) had access to the same private key? >> if you trust the first message, why would you not trust a >> replacement with equivalent "credentials" ? Ian> I may be happy to receive it, but not necessarily for it to Ian> destroy or cause another message to be obscured. i think that is less a security issue and more a GUI/policy issue. d From ilister at dstc.edu.au Tue Apr 9 12:08:09 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ??) In-Reply-To: <200204090139.g391dak06301@xevious.dstc.monash.edu.au> Message-ID: On Tue, 9 Apr 2002, David Arnold wrote: >you can send a new key in a message "authenticated" by a key from the >previous sequence. Ah yes. It's not just rekeying that's susceptible to this kind of attack (essentially a form of man-in-the-middle); every message can have its hash taken and reused so you end up with two valid-looking replacements for the same message. > Ian> You don't need to do it out of band. You just send your public > Ian> key with your messages and consumers can verify that subsequent > Ian> messages were signed by an entity holding the same private key > Ian> as that which signed the first message. > >does this actually get you any greater confidence than using a >producer-scheme key? in both cases, all it proves is that the message >sender(s) had access to the same private key? Yes, it allows you to verify invidual producers, as opposed to just verifying that the producer is in the (possibly rather large or even infinite) set of producers permitted to send notifications that match a particular subscription. > Ian> I may be happy to receive it, but not necessarily for it to > Ian> destroy or cause another message to be obscured. > >i think that is less a security issue and more a GUI/policy issue. No, I definitely think it's a security issue. There's no point in having this mechanism if the original message isn't at least obscured in some manner, but as soon as you allow messages to replace others without appropriate security measures (where I believe `appropriate' means more than just making sure the producer has rights to send to you) you have a potential attack. Ian From arnold at dstc.monash.edu.au Tue Apr 9 12:24:47 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: Message-ID: <200204090219.g392Jck06483@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: >> does this actually get you any greater confidence than using a >> producer-scheme key? in both cases, all it proves is that the >> message sender(s) had access to the same private key? Ian> Yes, it allows you to verify invidual producers, as opposed to Ian> just verifying that the producer is in the (possibly rather Ian> large or even infinite) set of producers permitted to send Ian> notifications that match a particular subscription. ok, so that seems to be the crux of the issue. it would be possible to achieve this by using a subscription together with key(s) obtained from the sender to achieve the same result, but you'd prefer to have a single, potentially more broad, subscription, and do application-level checks on replacement messages. while this basically introduces a redundant means of authenticating messages, i suppose it *might* be easier to implement. Ian> There's no point in having this mechanism if the original Ian> message isn't at least obscured in some manner, well, i'd debate that too. i'm perfectly happy with an insecure mechanism for almost all my tickertape usage, and my current usage of REPLACEMENT is no exception. Ian> but as soon as you allow messages to replace others without Ian> appropriate security measures (where I believe `appropriate' Ian> means more than just making sure the producer has rights to Ian> send to you) you have a potential attack. right. i'm happy with that, but i'm reluctant to require a duplicated mechanism. could you explain why you'd prefer this than using multiple subscriptions and careful handling of the deliveries to achieve the same result? d From arnold at dstc.monash.edu.au Tue Apr 9 12:39:09 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?) In-Reply-To: <200204090109.g3919fP04462@piglet.dstc.edu.au> Message-ID: <200204090234.g392Y1k06542@xevious.dstc.monash.edu.au> -->"Michael" == Michael Lawley writes: Michael> This is the solution that jumped to my mind, but not the Michael> n-replaces business since you only ever need to replace a Michael> given message once. the "2nd replacement" actually replaces Michael> the 1st replacement. So, separate the REPLACEMENT key from Michael> the REPLACEMENT_HASH and the replacement message should Michael> contain a hash of its own, new, plaintext. Michael> Does this make sense? almost ;-) what is the content of the REPLACEMENT_HASH field? d From arnold at dstc.monash.edu.au Tue Apr 9 18:45:23 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] presence protocol publication In-Reply-To: Message-ID: <200204090840.g398eDk08558@xevious.dstc.monash.edu.au> -->"Rainer" == Ruggaber, Rainer writes: Rainer, (quoting with permission ...) Rainer> just a quick question on the presence protocol. How would Rainer> you realize "substates"? Something like "online but on the Rainer> phone" or "in an elvinKonference"? would it be reasonable to Rainer> use the status-text? in my head, i translate the Status value "tokens" like online --> active unavailable? --> idle unavailable --> unavailable offline --> offline i personally find the semantics of the Status field confusing, and have suggested in the past that it be split and clarified, but i wasn't able to convince people ;-) for the cases above ("on the phone" or "in a conference"), you could - manually set your status to "unavailable", indicating that you did not wish to be disturbed - leave it in automatic mode, which will flip between "online" and "unavailable?" depending on how often you use the mouse or keyboard in addition, you could set some Status-Text message to indicate what you're doing, but this is really only useful to humans who speak your language ;-) Rainer> It seems that there might be some parsing problems. Would it Rainer> be better to use an extra field in the message for it? ignoring the message that you might leave for humans, what information are you trying to make available to programs? what use is it to a program to know you are using the phone instead of just idle, for example? Rainer> Is the Status field limited to the examples given in the Rainer> presence specification? (so is it something like an Rainer> enumeration?) it is not limited to these example, but, according to the latest draft it supports one other value -- "coffee", and any different value will be treated by programs as `falling between "unavailable" and "offline"', which is where "coffee" is as well (see section 3.8 of draft 0.4.1 of the spec). Rainer> I am asking all these questions because for some of our demo Rainer> applications it might be nice to have a presence protocol Rainer> that provides more detailed information. So something like a Rainer> generic presence protocol (with extensible states) would be Rainer> great. i'd be interested to hear what you might do with additional states. could you explain an example usage? d From ilister at dstc.edu.au Tue Apr 9 18:59:16 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] presence protocol publication In-Reply-To: <200204090840.g398eDk08558@xevious.dstc.monash.edu.au> Message-ID: On Tue, 9 Apr 2002, David Arnold wrote: >i personally find the semantics of the Status field confusing, and >have suggested in the past that it be split and clarified, but i >wasn't able to convince people ;-) Historically I have been guilty of not paying much attention to the presence protocol, but people may have noticed I've been taking a bit more interest recently :-) Could you point me to your proposal(s), David? (or reiterate them if you prefer). I would be keen to look at possible changes to the Status field... >it is not limited to these example, but, according to the latest draft >it supports one other value -- "coffee", and any different value will >be treated by programs as `falling between "unavailable" and >"offline"', which is where "coffee" is as well (see section 3.8 of >draft 0.4.1 of the spec). Ugh - that seems a bit bogus to me :-/ (I know, I know, sorry, I should have piped up earlier) Ian From arnold at dstc.monash.edu.au Wed Apr 10 10:09:28 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] presence protocol publication In-Reply-To: Message-ID: <200204100004.g3A04Dk13414@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> Could you point me to your proposal(s), David? (or reiterate Ian> them if you prefer). I would be keen to look at possible Ian> changes to the Status field... see the archives of ticker-dev from last november http://elvin.dstc.com/ListArchive/ticker-dev/archive/2001/11/ but, in summary, Status seems to have elements of multiple different properties munged into a single field. for example - activity / idleness ("online" / "unavailable?") - one time notification of client shutdown ("offline") - specific activity ("coffee") - explicit statement of unavailability ("unavailable") i hadn't ever proposed something i was happy with (from memory), but it still troubles me. d From arnold at dstc.monash.edu.au Wed Apr 10 11:29:54 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: on the use of user@foo Message-ID: <200204100124.g3A1Ock13839@xevious.dstc.monash.edu.au> following a lengthy ticker conversation this morning, i'd like to comment on the usage of the domain portion of user names, and how its use might be improved. in ticker, the use of name@domain has evolved as an extremely useful means of conveying the location of the sender. for example, "d@home" or "croy@work". as an historical aside, i believe this convention was initiated by Rik Taylor. in the current (0.4.1) draft of the presence protocol, a user (or presentity, to use the more specifc term) is identified by a _unique_ identifier formed from a combination of user and domain names. in current usage, however, this is not occurring. the convention of using the domain portion of the user's name to convey location information is carrying over. i have two issues with this: - it results in multiple presentities (at the protocol level) for a single person. when this is intentional (ie. you wish to present an alias), it's fine. it's my impression however that most people are simply using this as a means of conveying their location rather than as an attempt to create an alternate persona. - the use of common names like "home" or "work" for the domain portion of the identifier will cause collisions, leading to incorrect information about presentities. for example, David Arnold (DSTC) and David Parker (DSTO) are both current Presence-Protocol users. if we were both to use "david@home" as our identifier, the protocol would present a meaningless combination of our statuses. i'd like to propose two (really three) possible solutions to this problem: 1. since it appears (by observation, rather than interrogation ;-) that the main motivation for using different domain parts in users' identifiers is to convey their current location, perhaps we should add an explicit "Location" field to the Presence-Info notifications? clients would require users to specify their chosen _unique_ domain part (ie. a personally-owned domain, or their primary (maybe work?) domain) which would be used together with their user portion to form a unique name. additionally, the clients should allow the user to specify a location (ie. "home", "work", "laptop", etc) which would be sent in the Location field, and displayed in user interfaces. 2. following the same motivations, we could retain the definition of the User field as being a unique identifier, but add a second field for the Display-Name. in this case, clients would be configured with a unique identifier for the user/presentity, most likely their primary email address. the text string displayed in user interfaces however would be free-form text. this would enable the use of unique names like "da947456@yahoo.com" but would allow me to suggest a displayed name of "d@dstc", for example. it would also enable receiving clients to override the suggested display name, and have you see me as "ThatPickyBastard" if you wished. ultimately, i think i prefer a combination of these approaches: User-Id: "da947456@yahoo.com" Display-User: "d" Location: "monash" which allows your client to override my display name, but still get my location information. comments? d From arnold at dstc.monash.edu.au Wed Apr 10 14:21:17 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD9657D@XCH-BNE-01> Message-ID: <200204100416.g3A4G0k14591@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: (quoting from private mail with permission) <...> Martin> I realise that i'm entering an attribute naming conversation Martin> now, because I totally agree with the requirement. getting the names right is important ;-) Martin> User: "d" Martin> User-Name: "da947456@yahoo.com" Martin> User-Location: "monash" Martin> or another example .. Martin> User: "m@boeing" Martin> User-Name: "martin.wanicki@boeing.com" Martin> User-Location: "dstc.hq" section 3.1 of the spec v0.4.1 calls the unique name a ``userID''. maybe that's actually the best name for it? User-Id: "da947456@yahoo.com" User-Name: "d" User-Location: "monash" another option might be User-Alias (for the name to be displayed) ? Martin> I'm not sure if one alias is sufficient for people, perhaps Martin> some folks may want to do something like Martin> User: "foo@bar" Martin> User-Name: "anoymous.coward" Martin> User-Location: "home" Martin> I'm implying here that someone who may have a persona very Martin> well known as "anoymous.coward" may want to be seen as Martin> "foo@bar" mostly as an aside: in anonymous mode, clients probably shouldn't publish presence information. more on track though, if the string to be displayed has an `@' symbol in it, what are you proposing that we do with the Location value? i'd be tempted to ban `@' from both the requested display name and the location, and have clients display the presentity as (in a bogus pseudo-code) if Location and User-Alias: display_string = User-Alias@Location elif User-Alias and not Location: display_string = User-Alias elif not User-Alias and Location: display_string = "Anonymous@Location" else: display_string = User-Id i think Presence-Info notifications without the User-Id should be ignored. Martin> no one really knows (for this examples purposes) who Martin> "anoymous.coward" is but we do know that an entity most Martin> often known as "anoymous.coward" is to be referred to as Martin> "foo@bar" in presence and or tickertape. i'm happy for people to use a UUID/GUID (hashed or raw), or some other form of globally-unique identifier if they wish their real identity to be anonymous, but their presentity to be consistent. d From Martin.Wanicki at Australia.Boeing.com Wed Apr 10 15:14:59 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo Message-ID: <21BEC9503B89D111A8F700805FE6A3690BD966E3@XCH-BNE-01> I am in favour of making as few changes as possible and although section 3.1 talks about the User field as User Id, the notif format actually specifies User as the field name. Whatever we do I am also in favour of utilising as many attribute names as possible from the *new* tickertape spec refer to tickertape logs for the exchange between Julian and myself re a single notif being useful in multiple clients. Where I realise these are a separate domain, I'd really like to see standardisation among attribute names carrying the same or similar enough meaning.. ie User Timeout ...etc As far as I'm concerned the User in tickertape messaging is an alias, ie the name i wish to be known as for this message and (personally) the name I wish published as my presence alias. a real name or real identity/presentity attribute doesnt exist in either spec atm (imho) over to the masses .. regs, martin > ---------- > From: David Arnold[SMTP:arnold@dstc.monash.edu.au] > Reply To: davida@pobox.com > Sent: Wednesday, April 10, 2002 2:22 PM > To: ticker-dev@dstc.edu.au > Subject: Re: [ticker-dev] on the use of user@foo > > -->"Martin" == Wanicki, Martin > writes: > > (quoting from private mail with permission) > > <...> > > Martin> I realise that i'm entering an attribute naming conversation > Martin> now, because I totally agree with the requirement. > > getting the names right is important ;-) > > > Martin> User: "d" > Martin> User-Name: "da947456@yahoo.com" > Martin> User-Location: "monash" > > Martin> or another example .. > > Martin> User: "m@boeing" > Martin> User-Name: "martin.wanicki@boeing.com" > Martin> User-Location: "dstc.hq" > > section 3.1 of the spec v0.4.1 calls the unique name a ``userID''. > maybe that's actually the best name for it? > > User-Id: "da947456@yahoo.com" > User-Name: "d" > User-Location: "monash" > > another option might be User-Alias (for the name to be displayed) ? > > > Martin> I'm not sure if one alias is sufficient for people, perhaps > Martin> some folks may want to do something like > > Martin> User: "foo@bar" > Martin> User-Name: "anoymous.coward" > Martin> User-Location: "home" > > Martin> I'm implying here that someone who may have a persona very > Martin> well known as "anoymous.coward" may want to be seen as > Martin> "foo@bar" > > mostly as an aside: in anonymous mode, clients probably shouldn't > publish presence information. > > more on track though, if the string to be displayed has an `@' symbol > in it, what are you proposing that we do with the Location value? > > i'd be tempted to ban `@' from both the requested display name and the > location, and have clients display the presentity as (in a bogus > pseudo-code) > > if Location and User-Alias: > display_string = User-Alias@Location > elif User-Alias and not Location: > display_string = User-Alias > elif not User-Alias and Location: > display_string = "Anonymous@Location" > else: > display_string = User-Id > > i think Presence-Info notifications without the User-Id should be > ignored. > > > Martin> no one really knows (for this examples purposes) who > Martin> "anoymous.coward" is but we do know that an entity most > Martin> often known as "anoymous.coward" is to be referred to as > Martin> "foo@bar" in presence and or tickertape. > > i'm happy for people to use a UUID/GUID (hashed or raw), or some other > form of globally-unique identifier if they wish their real identity to > be anonymous, but their presentity to be consistent. > > > > > > d > From Martin.Wanicki at Australia.Boeing.com Wed Apr 10 15:21:53 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo Message-ID: <21BEC9503B89D111A8F700805FE6A3690BD966F2@XCH-BNE-01> sorry, forgot to check the new spec seems that User is to become From that seems to work for me, a presence notification From: "foo@bar" this makes me want to call the field Originator tho! thus making the attrib name useful in more that one domain .... just a thought :-) martin From Martin.Wanicki at Australia.Boeing.com Wed Apr 10 15:36:38 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:42 2003 Subject: Attribute Naming Message-ID: <21BEC9503B89D111A8F700805FE6A3690BD96725@XCH-BNE-01> Thinking further about things, I put forward for debate the notion of a standard bucket of attribute names that different notification formats draw on to build their specs. A spec for names being something like ... Name Meaning ========================= Originator The Human originator of a notification Originator-Agent The Software application that originated/produced the notification Protocol-Name The name of the protocol this notification belongs to Protocol-Version The version of the protocol this notification conforms to Timeout The Suggested lifetime of the message, in minutes ...etc and then individual spec could be made up of any of the elements in the naming spec this, I think would make the building of spec easier and at the same time making interoperability between clients easier thoughts ? Martin From arnold at dstc.monash.edu.au Wed Apr 10 15:40:05 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: Attribute Naming In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD96725@XCH-BNE-01> Message-ID: <200204100534.g3A5Ylk15179@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: Martin> Thinking further about things, I put forward for debate the Martin> notion of a standard bucket of attribute names that Martin> different notification formats draw on to build their specs. i think this is Julian's cue ... d From arnold at dstc.monash.edu.au Wed Apr 10 15:50:02 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: Attribute Naming In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD96725@XCH-BNE-01> Message-ID: <200204100544.g3A5ijk15263@xevious.dstc.monash.edu.au> i'll comment on these two, since i have spent some thinking time on it over the years. Protocol-Name Protocol-Version my favourite way of doing this at the moment is name: version the benefit of having the name as a field name, rather than a value, is that you can have multiple standards supported in the same notification, and you can select using require(), which is more efficient than a string comparison. the version is an int32 value calculated like: major * 1000 + minor the advantage of this scheme is that it allows simple checks for known incompatible versions, XXXX >= 1003 && XXXX < 4000 which seems easier than string tests or using floating point values. an example of this is in the presence protocol, Presence-Protocol: 1000 although i tend to prefer less collision-prone format names d From blaize at dstc.edu.au Wed Apr 10 15:52:00 2002 From: blaize at dstc.edu.au (Blaize Rhodes) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Re: Attribute Naming In-Reply-To: <200204100534.g3A5Ylk15179@xevious.dstc.monash.edu.au> Message-ID: <000b01c1e054$31106fc0$0100a8c0@snoopy> I think it's a good idea. cheers blaize ----- Original Message ----- From: "David Arnold" To: Sent: Wednesday, April 10, 2002 3:40 PM Subject: [ticker-dev] Re: Attribute Naming > -->"Martin" == Wanicki, Martin writes: > > Martin> Thinking further about things, I put forward for debate the > Martin> notion of a standard bucket of attribute names that > Martin> different notification formats draw on to build their specs. > > i think this is Julian's cue ... > > > > d From ilister at dstc.edu.au Wed Apr 10 15:52:31 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD966E3@XCH-BNE-01> Message-ID: On Wed, 10 Apr 2002, Wanicki, Martin wrote: >I am in favour of making as few changes as possible and although section 3.1 >talks about the User field as User Id, the notif format actually specifies >User as the field name. Clearly the intention of the current presence and ticker specs have slightly different meanings of `User'. In ticker it's particularly informal and may be used as a lightweight way to convey some presence or location information. In presence it's required to be a more formal unique and consistent user identifier (and David has reasonably proposed that a loose display name a la ticker should also be supported). Hence I suggest that names that convey each meaning appropriately are chosen and used consistently between the specs. Ian From arnold at dstc.monash.edu.au Wed Apr 10 16:07:06 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BD966E3@XCH-BNE-01> Message-ID: <200204100601.g3A61mk15419@xevious.dstc.monash.edu.au> -->"Martin" == Wanicki, Martin writes: Martin> I am in favour of making as few changes as possible and Martin> although section 3.1 talks about the User field as User Id, Martin> the notif format actually specifies User as the field name. i'm in favour of getting it right, using as few changes as possible ;-) Martin> Whatever we do I am also in favour of utilising as many Martin> attribute names as possible from the *new* tickertape spec consistent naming for fields with the same semantics is a fine thing. we have (had)? a golden opportunity to get both presence and chat consistent. given the releases of eTiks, aquatik and sticker using draft formats, this opportunity might be over now, but ... ? Martin> Where I realise these are a separate domain, I'd really like Martin> to see standardisation among attribute names carrying the Martin> same or similar enough meaning.. yep. Martin> As far as I'm concerned the User in tickertape messaging is Martin> an alias, ie the name i wish to be known as for this message Martin> and (personally) the name I wish published as my presence Martin> alias. except that we're talking about separating the location and the name in the presence spec. no one has proposed that for ticker (yet). i don't want to force ticker users to supply a location (although the convention i suggested for constructing presence displayed names from Location and User-Alias would probably work fine ...) Martin> a real name or real identity/presentity attribute doesnt Martin> exist in either spec atm (imho) where "real" means something that can be tracked to your real self, no. but presence does have the "unique" requirement for userID. i would be extremely dubious of any requirement for a traceable identity. d From Matthew.Phillips at dsto.defence.gov.au Wed Apr 10 16:14:34 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] on the use of user@foo Message-ID: <8FCECF5E61F0D511946000306E0189F812E589@ednex504.dsto.defence.gov.au> What he said: I agree with David's observations and suggested extensions except that, like Martin, I'd much prefer that the existing "User" field be kept as the User ID for backwards compatibility (while I wholeheartedly agree with getting field names right to start with, once they're "out there" I say live with them except where the pain of changing is less than having to use the protocol). Using your email address as the ID might be a bit controversial due to possible use by spammers, but as long as you can change it, it shouldn't be a real issue, and it is the only really safe default. Matt. > -----Original Message----- > From: David Arnold [mailto:arnold@dstc.monash.edu.au] > Sent: Wednesday, 10 April 2002 11:01 AM > To: ticker-dev@dstc.edu.au > Subject: [ticker-dev] on the use of user@foo > > > following a lengthy ticker conversation this morning, i'd like to > comment on the usage of the domain portion of user names, and how its > use might be improved. > > in ticker, the use of name@domain has evolved as an extremely useful > means of conveying the location of the sender. for example, > "d@home" or "croy@work". as an historical aside, i believe this > convention was initiated by Rik Taylor. ... From Matthew.Phillips at dsto.defence.gov.au Wed Apr 10 16:39:42 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] presence protocol publication Message-ID: <8FCECF5E61F0D511946000306E0189F812E58A@ednex504.dsto.defence.gov.au> > but, in summary, Status seems to have elements of multiple different > properties munged into a single field. for example > > - activity / idleness ("online" / "unavailable?") > - one time notification of client shutdown ("offline") > - specific activity ("coffee") > - explicit statement of unavailability ("unavailable") > > i hadn't ever proposed something i was happy with (from memory), but > it still troubles me. I feel the need to defend this ;) The "Status" field of the user is intended to convey the status of the user in regard to *online communication* (ticker messaging is assumed): "online" = user says they are online for communication. "unavailable" = user says they are not available for communication now, but ARE still running a client. ie there might be some point in sending a personal message if you really need to talk. "unavailable?" = client has guessed that the user is probably unavailable, but it might be worth trying anyway "coffee" = the same as "unavailable". It's a standard value so that presence can be used to subsume coffeebiff, ie so that clients can watch for people who are on coffee break. I suppose other values could also be used for specific purposes (eg "meeting" might be interpreted specially by some clients), but I think it's safest for general clients to conservatively treat unspecified values as meaning "unavailable". "offline" = Not available at all, don't bother sending anything, they aren't going to receive it. This will usually be because the client has exited, but that's just the most common cause of "offlineness". Yes, in retrospect "Status" might have been better named "Communication-Status" or something, but I am beginning to think that getting too anal about field naming is one way to madness ;) Cheers, Matt. From phelps at dstc.edu.au Thu Apr 11 06:38:59 2002 From: phelps at dstc.edu.au (Ted Phelps) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Re: Attribute Naming In-Reply-To: <200204100544.g3A5ijk15263@xevious.dstc.monash.edu.au> Message-ID: <200204102038.g3AKcpog003971@dstc.edu.au> David Arnold may have said: > ...and you can select using require(), which is more efficient than > a string comparison. As an aside, I'd like to point out that although this statement is currently true, it will not necessarily be so in the future, so let's net let it affect our decisions. The reasoning behind this statement is a corollary of what David was already saying: if Protocol-Name is "foo" then Protocol-Name cannot also be "bar" (although require(foo) and require(bar) can both be true). The evaluation engine could (and eventually will) be able to take advantage of this fact to prune its search tree, possibly eliminating many other tests and making string equality the faster test. Cheers, -Ted From julian at dstc.monash.edu.au Thu Apr 11 09:46:38 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Re: Attribute Naming In-Reply-To: <200204100544.g3A5ijk15263@xevious.dstc.monash.edu.au> Message-ID: <200204102340.g3ANeQk20705@xevious.dstc.monash.edu.au> David Arnold wrote: > i'll comment on these two, since i have spent some thinking time on it > over the years. > > Protocol-Name > Protocol-Version > > my favourite way of doing this at the moment is > > name: version > > the benefit of having the name as a field name, rather than a value, > is that you can have multiple standards supported in the same > notification, and you can select using require(), which is more > efficient than a string comparison. The former of these becomes the killer, IMO. If we had lists, then you could have a single Protocols attribute which contained multiple tags. However, we don't, so using Protocol-Name limits each well-formed notification to a single domain. We never want to require that. From an asthetic viewpoint, I prefer the usability of Protocol-[Name|Version] rather than David's version number mangling. The mangling, while useful and sufficient from a technical perspective, limits the readibility of raw notifications by mortal users. However, protocol versions and formats I do not consider as import to be readable and understandable by users as the actual notification data. (side issue: In general, I believe easily understood notifications are an important aspect of keeping elvin useful. If notifications are easy to read, then users can more easily and relaible configure their consumers to get the information they want.) Another point: I think Protocol is the wring term - A protocol usually defines mulitple interactions. I think "Format" is a better term in the current context, as we are talking about the specific format of a notification which may be part of a more complex protocol. "Type" is also an alternative... as far as i'm concerned, i'm torn with the format/version meta-data in an even being simple, and it being machine useful for downloading event formats. I think general data-naming is alot simpler and can following general mata-data/cataloging standards which I have started reviewing. So, for tickertape, perhaps somthing like: Tickertape-Format: "http://www.elvin.org/EF/tickertape-3000.xml" Tickertape-Version: 3000 maybe ...? -J From arnold at dstc.monash.edu.au Thu Apr 11 12:54:15 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Re: Attribute Naming In-Reply-To: <200204102038.g3AKcpog003971@dstc.edu.au> Message-ID: <200204110248.g3B2m2k22242@xevious.dstc.monash.edu.au> -->"Ted" == Ted Phelps writes: Ted> David Arnold may have said: >> ...and you can select using require(), which is more efficient >> than a string comparison. Ted> As an aside, I'd like to point out that although this statement Ted> is currently true, it will not necessarily be so in the future, Ted> so let's net let it affect our decisions. i agree that performance should not really be a consideration. as an interesting, but irrelevant excursion then ... Ted> The reasoning behind this statement is a corollary of what Ted> David was already saying: if Protocol-Name is "foo" then Ted> Protocol-Name cannot also be "bar" (although require(foo) and Ted> require(bar) can both be true). The evaluation engine could Ted> (and eventually will) be able to take advantage of this fact to Ted> prune its search tree, possibly eliminating many other tests Ted> and making string equality the faster test. in that the engine won't have to compare a candidate notification against all registered subscriptions? and because !require() == bottom means we cannot prune the tree? this really highlights how difficult it is to talk meaningfully about performance :-( d From ilister at dstc.edu.au Thu Apr 11 14:27:48 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 spec In-Reply-To: <200204060523.g365N8k23891@xevious.dstc.monash.edu.au> Message-ID: On Sat, 6 Apr 2002, David Arnold wrote: >2. Distribution > > Matthew and Martin are keen to have this feature, possibly with > standardised semantics for its values. I have come to the conclusion that I would quite like this in the presence protocol too. I would like my co-workers to know that I am in some confidential meeting (hypothetically speaking) but I don't particularly want to tell the world (I just want them to know I'm in `a' meeting), or maybe I may not want other organisations to know that I'm off drinking beer at 10am on Monday (hypothetically speaking). Thus, I would be able to specify one lot of status information and restrict it to be organisation local, and another lot for global distribution. I would send both these notifications in response to requests and administrative filters would cut out anything org local at my organisational boundaries (similarly for site boundaries, etc). Nearby clients would receive both lots of information and take the most local information as the most useful and display it, while people in other organisations would receive only the global information. This would be another example of an attribute that can have a consistent meaning across several application domains, in this case allowing much easy federation config (this could even be put in the default config files). Sorry if this mail is a bit scattered (it would just be reflecting me atm) but hopefully I've got my point across. Comments welcome :-) Ian From Martin.Wanicki at Australia.Boeing.com Thu Apr 11 16:12:36 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 & presence spec Message-ID: <21BEC9503B89D111A8F700805FE6A3690BE4968F@XCH-BNE-01> I like this as a concept, *but* I dont want to have to emit multiple scope-based notifications. as an example - in eTiks when you use the optional extra attribute (I use for domain scoping), it gets appended to EVERY emitted notification INCLUDING presence, so I can set my presence info to "unavailable" for the world to receive, then turn on the domain restriction attribute and send an "available" the net result being the world thinks I'm unavailable and until I turn of the domain restriction attribute, will continue to do so. Course I realise this is NOT the best way to do this, but it IS a way to get a square peg in a round hole :-/ some random thoughts.... changing a setting for a single status change to reflect all the different ways I want this status change to be seen by different people in different domains seems to be a little broken to me, perhaps I'm misunderstanding. The answer here seems to indicate a personal presence bot, that see's only my presence info's and based on rules emits the appropriate presence notification, properly scoped. I certainly dont have the time or inclination to build this into etiks, although this functionality *may* be desirable. One could, of course, run multiple clients, each configured differently, but i dont think thats the answer either. Hmmm, Distribution for presence doesnt really seem do-able, I think we have a case for domain policy here in defining the status descriptions that are allowable within a domain something along the lines of the following . the status description "Meeting" is allowed beyond the domain perimiter, but the the status description "(Meeting)" is NOT allowed beyond the domain perimiter. I dunno what the answer is, it'd be really good if we could keep it simple and elegant :-) martin > ---------- > From: Ian Lister[SMTP:ilister@dstc.edu.au] > Sent: Thursday, April 11, 2002 2:27 PM > To: ticker-dev@dstc.edu.au > Subject: Re: [ticker-dev] ticker-3.0 spec > > On Sat, 6 Apr 2002, David Arnold wrote: > >2. Distribution > > > > Matthew and Martin are keen to have this feature, possibly with > > standardised semantics for its values. > > I have come to the conclusion that I would quite like this in the presence > protocol too. I would like my co-workers to know that I am in some > confidential meeting (hypothetically speaking) but I don't particularly > want to tell the world (I just want them to know I'm in `a' meeting), or > maybe I may not want other organisations to know that I'm off drinking > beer at 10am on Monday (hypothetically speaking). > > Thus, I would be able to specify one lot of status information and > restrict it to be organisation local, and another lot for global > distribution. I would send both these notifications in response to > requests and administrative filters would cut out anything org local at my > organisational boundaries (similarly for site boundaries, etc). Nearby > clients would receive both lots of information and take the most local > information as the most useful and display it, while people in other > organisations would receive only the global information. > > This would be another example of an attribute that can have a consistent > meaning across several application domains, in this case allowing much > easy federation config (this could even be put in the default config > files). > > Sorry if this mail is a bit scattered (it would just be reflecting me atm) > but hopefully I've got my point across. Comments welcome :-) > > Ian > From Martin.Wanicki at Australia.Boeing.com Thu Apr 11 16:44:29 2002 From: Martin.Wanicki at Australia.Boeing.com (Wanicki, Martin) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Re: Attribute Naming - user@domain debarcle Message-ID: <21BEC9503B89D111A8F700805FE6A3690BE496DB@XCH-BNE-01> Sticking my nose in yet again, Perhaps as in the presence spec where a single attribute is able to carry multiple values, the user field is mandated to also contain multiples values (at most two) then *suggest* that folks keep the first part stable and do what they like with the last part, ooh this is sounding like I'm an advocate for keeping things the way they are, oops :-) I seem to remember a conversation about presence mentioning that the @domain portion of a username has no meaning to the presence protocol, anyone remember that ?? So if presence clients actually ignore or strip out the @domain part of a user field for identification purposes we get rid of all our problems presence can still use this info a little like it uses client id. ducks, weaves, runs like hell martin From ilister at dstc.edu.au Thu Apr 11 16:59:36 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] ticker-3.0 & presence spec In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690BE4968F@XCH-BNE-01> Message-ID: On Thu, 11 Apr 2002, Wanicki, Martin wrote: >I like this as a concept, *but* I dont want to have to emit multiple >scope-based notifications. If you don't want to implement it in eTiks you don't have to. There's no need for it to be mandatory. >as an example - in eTiks when you use the optional extra attribute (I use >for domain scoping), it gets >appended to EVERY emitted notification INCLUDING presence, >so I can set my presence info to "unavailable" for the world to receive, >then turn on the domain restriction attribute and send an >"available" > >the net result being the world thinks I'm unavailable and until I turn of >the domain restriction attribute, will continue to do so. Of course this only sort-of works, as subsequent requests by external people won't get any response from you. You can choose to stick with this way of dealing with it if you like, but my proposal allows other users to get extra value out of the protocol. >changing a setting for a single status change to reflect all the different >ways I want this status change to be seen by different people >in different domains seems to be a little broken to me, perhaps I'm >misunderstanding. I'm not quite sure what you mean. How this functionality is presented to the user (if at all) is up to anybody who wants to implement it. It seems to me that if you want different people to see different things you have to specify both of those different things somehow. It's an open question exactly how - you could have your client preconfigured with rules (like your `Meeting', `(Meeting)' stuff), or you could have a separate agent (bot, if you like) on the network doing that (as you proposed). Either way, I think adding the Distribution tag only enables these things, and allows clients to deal with it as they like (if at all). >The answer here seems to indicate a personal presence bot, that see's only >my presence info's and based on rules >emits the appropriate presence notification, properly scoped. >I certainly dont have the time or inclination to build this into etiks, >although this functionality *may* be desirable. As above, I think this allows a personal presence bot (translating your organisation-local notifications to global ones). It also allows the functionality to built into the end-user's presence client if you want. >One could, of course, run multiple clients, each configured differently, but >i dont think thats the answer either. It's an answer, but probably not ideal for the user :-) >Distribution for presence doesnt really seem do-able, I don't agree. >I think we have a case for domain policy here in defining the status >descriptions that are allowable within a domain >something along the lines of the following . > > the status description "Meeting" is allowed beyond the domain >perimiter, but the > the status description "(Meeting)" is NOT allowed beyond the domain >perimiter. That is certainly one approach, and is not at all incompatible with my suggestion. >I dunno what the answer is, it'd be really good if we could keep it simple >and elegant :-) Sure - I'm all for that too! :-) Ian From Matthew.Phillips at dsto.defence.gov.au Fri Apr 19 15:11:52 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: Presence in eTiks and aquatik Message-ID: <8FCECF5E61F0D511946000306E0189F812E5B0@ednex504.dsto.defence.gov.au> Hi guys, I've just been watching presence notifications bounce back and forth and noticed that, apparently, eTiks and aquatik are being a little too promiscuous with the Presence-Requests they reply to. Below is a log of the case where a Sticker has decided that Ian, David and Clinton have been too quiet and pings them with: Presence-Request: "d5d405fe6ef6623" Presence-Protocol: 1000 Requestor: "asenstoj@elvin" Users: "|ilister@dstc|d@0x1.org|croy@dstc|" Groups: "" The responses shown below come back, which include unrequested replies from "rernst@boeing", "dudek" and Michael. Michael/Martin, do eTiks and aquatik look at the Users field, or do they just respond to any Presence-Request? Cheers, Matthew. Status-Text: "@work" Client-Id: "4b1716ba2dcbdba0bff58a7ce2830678c80b0d8b" Presence-Info: "d5d405fe6ef6623" Status: "online" Status-Duration: 105194 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0t/python-2.1/SunOS-5.8)" UNCLASSIFIED: 1 Groups: "|Chat|dstc|elvin|elvin-dev|ticker-dev|level7|Coffee|" Classification: "UNCLASSIFIED" User: "croy@dstc" --- Status-Text: "At work" Client-Id: "1a0a43129b689d220b91c39635df0b72b9e23f4d" Presence-Info: "d5d405fe6ef6623" Status: "online" Status-Duration: 15047 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0b4/python-2.1/SunOS-5.8)" UNCLASSIFIED: 1 Groups: "|Chat|dstc|elvin|elvin-dev|ticker-dev|osx|OSX|level7|Coffee|" Classification: "UNCLASSIFIED" User: "ilister@dstc" --- Status-Text: "@ monash" Client-Id: "cbcbf4cbc5509c75eb1b9f29146125bdbb162fac" Presence-Info: "d5d405fe6ef6623" Status: "online" Status-Duration: 21775 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0t/python-2.1/SunOS-5.8)" UNCLASSIFIED: 1 Groups: "|elvin|dstc|dstc-monash|ticker-dev|" Classification: "UNCLASSIFIED" User: "d@0x1.org" --- Status-Text: "waking up" Client-Id: "3caa5f27214d22790d4f3f1bd763aa64619691a0" Presence-Info: "d5d405fe6ef6623" Status: "online" Status-Duration: 25512 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0t/python-2.1/Linux-2.4.7)" UNCLASSIFIED: 1 Groups: "|Chat|dstc|elvin|elvin-dev|ticker-dev|level7|Coffee|" Classification: "UNCLASSIFIED" User: "croy@dstc" --- Status-Text: "Asleep" Client-Id: "9eea2463b654f32e15e752a19419f5078eb1bc52" Presence-Info: "d5d405fe6ef6623" Status: "unavailable" Status-Duration: 55402 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0b4/python-2.2/FreeBSD-4.2-RELEASE)" UNCLASSIFIED: 1 Groups: "|Chat|dstc|elvin|elvin-dev|ticker-dev|osx|OSX|level7|Coffee|" Classification: "UNCLASSIFIED" User: "ilister@dstc" --- Status-Text: "heading in" Client-Id: "ddf47a178e4576966955f7ebada0b025f96917b7" Presence-Info: "d5d405fe6ef6623" Status: "unavailable" Status-Duration: 23724 __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "generic" Presence-Protocol: 1000 User-Agent: "epm v1.0.0 (pe-4.0t/python-2.1/Linux-2.4.14)" UNCLASSIFIED: 1 Groups: "|elvin|dstc|dstc-monash|ticker-dev|" Classification: "UNCLASSIFIED" User: "d@0x1.org" --- Status-Text: "Away" Client-Id: "e0f63617ad099aa6cdbacdd764c89a5804e4d6b1" Presence-Info: "d5d405fe6ef6623" Status: "unavailable?" X-Federated-From-Boeing: 1 Status-Duration: 16901 __ewaf: "elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "eTiks 1.0.11.0" Presence-Protocol: 1000 User-Agent: "eTiks 1.0.11.0" UNCLASSIFIED: 1 Groups: "||dstc|aquatik|osx|OSX|boeing|b.hq|boeing.aus.hq|cis|" Classification: "UNCLASSIFIED" User: "rernst@boeing" --- Status-Text: "Online" Presence-Info: "initial" Status: "online" Status-Duration: 37022L __ewaf: "elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "aquatik" Presence-Protocol: 1000L User-Agent: "aquatik-1.0" UNCLASSIFIED: 1 Groups: "|localhost|aquatik|" Classification: "UNCLASSIFIED" User: "dudek" --- Status-Text: "Online" Presence-Info: "initial" Status: "online" Status-Duration: 15193L __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "aquatik" Presence-Protocol: 1000L User-Agent: "aquatik-1.0" UNCLASSIFIED: 1 Groups: "|dstc|Chat|elvin|aquatik|" Classification: "UNCLASSIFIED" User: "lawless@osx" --- Status-Text: "Online" Presence-Info: "initial" Status: "online" Status-Duration: 144210L __ewaf: "hq.dstc.com | elvin.dstc.com | elvin://picasso.dsto.defence.gov.au" Ticker-Client: "aquatik" Presence-Protocol: 1000L User-Agent: "aquatik-1.0" UNCLASSIFIED: 1 Groups: "|dstc|aquatik|" Classification: "UNCLASSIFIED" User: "ilister" From bill at dstc.edu.au Mon Apr 22 19:32:34 2002 From: bill at dstc.edu.au (Bill Segall) Date: Tue Oct 14 08:01:42 2003 Subject: Ontologies etc [ was Re: Attribute Naming ] In-Reply-To: <200204102340.g3ANeQk20705@xevious.dstc.monash.edu.au> Message-ID: <200204220932.g3M9WYr06071@piglet.dstc.edu.au> I'd like to broaden this thread so I've cross-posted this to elvin-dev and ticker-dev and sent followups to elvin-dev as I think the ramifications are broader than just the tickertape application. I've been on holidays so please excuse my late entrance to the debate. Starting from a philosophical background, I believe when it comes to ontologies we're always going to be left with imperfection because the world is a complex, illogical, and poorly defined place. Any spoken language is a good example of this and I'll leave the ontological implications of Godel's proof for someone with more talent in both fields (maths and linguistics) than myself. That aside, what we seem to be trying to achieve is a simpler but still quite difficult task - a set of naming principles and recommendations for application naming and versioning. A desirable set of attributes would seem to be: * clarity * applicability to all applications * applicability to multiple simultaneous applications * Implication of a set of semantic constraints Within Elvin it is not nor will it ever be possible to enforce semantic constraints based upon some particular attribute being specified. (i.e, subscribing to a specific attribute cannot guarantee the presence or absence of others). This is very desirable in terms of flexibility and keeps the notion of Elvin being dynamic in terms of both publishing and subscribing. It means we don't require pre-publication of formats, metadata, or MIB style nonsense. If you don't agree with this then Elvin is not the droid you're looking for :-) It's fundamental to Elvin's model, performance, and scalability. So, no attribute can mandate that merely subscribing to that attribute will give you correctly structured messages. This is a good way of crashing (or raising an exception for those (blighted souls :-) who believe in generosity of languages) because someone else didn't obey the rules. We will endeavour to support the rules by being "strict in what we send and generous in what we receive" - who said this and in what context? The end result is that we shouldn't be using these attributes as subscription fodder but should be using the underlying fields we really expect to be there. It's the only way to be sure and obeys the Elvin principle of subscribing on the content you want rather than a topic or channel. This leaves us with using things like protocol version numbers and names as a mark of conformance and of making things readable. This is highly desirable and also addresses clarity from the intent side. My difficulty with the current use of something like: org.elvin.tickertape: 1.1 ... tickertape attributes is that the attribute is not shared and subscribable without knowing it's name. My difficulty with: protocol.name: "org.elvin.tickertape" protocol.version.major: 1 protocol.version.minor: 1 ... tickertape attributes is that I can't support two versions of the same protocol or two different protocols in the same notification. (Whether we split major/minor or make it textual is one of those difficult things - rpm uses the textual approach and it hurts). If we had a message that supported two different protocols we might do something like: protocol.names: "org.elvin.tickertape biz.elvin.coffeebiff" protocol.version.org.elvin.tickertape: 1.1 protocol.version.biz.elvin.coffeebiff: 2.0 ... tickertape attributes ... coffeebiff attributes If someone wanted to subscribe to a particular protocol they would be forced into using a regular expression (or wildcard) on protocol.names but I'm hoping that I've successfully argued that this is a bad thing regardless. Having an attribute like "protocol.version.org.elvin.tickertape" is exceptionally ugly. Could we compromise this to a mix of Julian and David like this? protocol.names: "org.elvin.tickertape biz.elvin.coffeebiff" org.elvin.tickertape: 1.1 biz.elvin.coffeebiff: 2.0 ... tickertape attributes ... coffeebiff attributes We could add in things like the spec via: org.elvin.tickertape.spec: "http://..." (and I kind of like the reference in the events although every time we do this we soak up bandwidth). To finish, I think it's really important that we define a set of recommendations, possibly in the form of an RFC but at least initially just as as html on the Elvin web. It needs examples (hopefully for xtickertape) that helps people. I'm not really happy with any of the compromises above so what might be better? What extra information (liek spec references) do we want to track? How do we want to represent versions? I'll write this up somewhere if we can reach some sort of consensus. I think this is sufficiently important that we need to reach some form of agreement on a v1 spec for this in the short-term. Bill. From sachink at dstc.edu.au Thu May 16 13:13:00 2002 From: sachink at dstc.edu.au (Sachin Kulkarni) Date: Tue Oct 14 08:01:42 2003 Subject: need help re Web services for Elvin! Message-ID: <000501c1fc87$969e8440$d2b16682@somepc210> Hi All, I am trying to develop a web service using Elvin ActiveX add-on (xe4) with C#. Connection and generating notifications works fine. I need some help in receiving notification and adding eventHandler for handling notifications. Can anyone help? It would be very similar to C++/Java. Sachin     From kas-list at magnetic-ink.dk Thu Jul 11 19:08:32 2002 From: kas-list at magnetic-ink.dk (Klaus Alexander Seistrup) Date: Tue Oct 14 08:01:42 2003 Subject: Merging chat and news messages? Message-ID: <20020711090826.GA23725@magnetic-ink.dk> G'day mates, Currently, most clients are using the "old" notification formats to broadcast chat and news messages (chat v1.3 and news v1.0), as per the specs on . I was under the impression that the org.tickertape.message v2.0 was supposed to merge chat and news messages into a unified message format - a step that I welcome, since it somehow simplifies the writing of client implementations. However, recently David pointed me towards a v3 draft of the chat protocol, mentioned in . The memo specifies a "Message" field, which would contain "text to be displayed in the scroller (or similar user interface location)". In spite of the memo title, "Tickertape Chat Protocol", I assume that v3 is also a unified message format that will handle both chat and Usenet messages - or at least this is wishful thinking - but I'm not sure how to implement this in my tickertape client(s). Chat notifications need a field, currently labeled "Message", for the message content. Usenet notifications need an extra field that will hold the article contents. Both "Message" and "Body" are good candidate names for that field, except "Message" is used for short scroller messages in chat notifications, and cannot be used for article contents. It would seem that Usenet notifications need a "Subject" and a "Body" field, where the "Subject" field is equivalent to the "Message" field in chat notifications, but this scheme is counterproductive if the goal is to unify the two notification formats. Does anyone have a good naming scheme that would allow us to use the same notification format for chat and news messages? Or should we simply keep the two formats separate, as in the old protocols? On a side note, I would find it useful to have two optional fields: (1) a "Summary" field, that would summarize the contents of a news message (or perhaps we should just use the "Subject" type of field for that?), and (2) a "Keywords" field containing e.g. a comma (or even whitespace) separated list of keywords. Whaddyathink? // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From Matthew.Phillips at dsto.defence.gov.au Fri Jul 12 14:17:53 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Merging chat and news messages? Message-ID: <108E7D907871D6118B5000306E0189F8A67007@ednex504.dsto.defence.gov.au> Hi Klaus/all, since we're happily going to be breaking backwards compatibility anyway, I'd vote we use "Subject" for the tickertext/usenet subject and "Body" for the message content (if any)? Ticker clients would show the Subject in the ticker and the body when the user "opens" or "selects" the message. I think having the same core set of fields for Usenet and ticker is an excellent goal, although it should also be possible to tell the two types apart if necessary. I like the idea of having a keywords field. Cheers, Matthew. > -----Original Message----- > From: kas-list@magnetic-ink.dk [mailto:kas-list@magnetic-ink.dk] > Sent: Thursday, 11 July 2002 6:38 PM > To: Tickertape Development > Subject: [ticker-dev] Merging chat and news messages? > > > G'day mates, > > Currently, most clients are using the "old" notification > formats to broadcast chat and news messages (chat v1.3 and > news v1.0), as per the specs on > . > > I was under the impression that the org.tickertape.message > v2.0 was supposed to merge chat and news messages into a > unified message format - a step that I welcome, since it > somehow simplifies the writing of client implementations. > > However, recently David pointed me towards a v3 draft of the > chat protocol, mentioned in > . The memo specifies a "Message" field, which would contain "text to be displayed in the scroller (or similar user interface location)". In spite of the memo title, "Tickertape Chat Protocol", I assume that v3 is also a unified message format that will handle both chat and Usenet messages - or at least this is wishful thinking - but I'm not sure how to implement this in my tickertape client(s). Chat notifications need a field, currently labeled "Message", for the message content. Usenet notifications need an extra field that will hold the article contents. Both "Message" and "Body" are good candidate names for that field, except "Message" is used for short scroller messages in chat notifications, and cannot be used for article contents. It would seem that Usenet notifications need a "Subject" and a "Body" field, where the "Subject" field is equivalent to the "Message" field in chat notifications, but this scheme is counterproductive if the goal is to unify the two notification formats. Does anyone have a good naming scheme that would allow us to use the same notification format for chat and news messages? Or should we simply keep the two formats separate, as in the old protocols? On a side note, I would find it useful to have two optional fields: (1) a "Summary" field, that would summarize the contents of a news message (or perhaps we should just use the "Subject" type of field for that?), and (2) a "Keywords" field containing e.g. a comma (or even whitespace) separated list of keywords. Whaddyathink? // Klaus -- A man, just one - also a fly, just one - in the huge drawing room. From arnold at dstc.monash.edu.au Tue Jul 16 12:32:11 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Merging chat and news messages? In-Reply-To: <20020711090826.GA23725@magnetic-ink.dk> Message-ID: <200207160212.g6G2Ctk03157@xevious.dstc.monash.edu.au> -->"Klaus" == Klaus Alexander Seistrup writes: Klaus> G'day mates G'day cob! :-) <...> Klaus> . <...> Klaus> Does anyone have a good naming scheme that would allow us to Klaus> use the same notification format for chat and news messages? Klaus> Or should we simply keep the two formats separate, as in the Klaus> old protocols? i'd welcome a merger, personally. the separation is historical, and i can't think of a good reason to retain it. it does revive the long-agonised-over naming discussion, but ... oh well. "Subject" and "Body" are tempting, although use of "Subject" for chat is a little disconcerting. Klaus> On a side note, I would find it useful to have two optional Klaus> fields: (1) a "Summary" field, that would summarize the Klaus> contents of a news message (or perhaps we should just use the Klaus> "Subject" type of field for that?), no objections to "Summary" as an optional field. it would be nice for things like the ABC news scraper, which actually has such a thing (but not a real "Body"). Klaus> and (2) a "Keywords" field containing e.g. a comma (or even Klaus> whitespace) separated list of keywords. no real objections to that either, although i'm less sure of its use, since presumably once could filter on any or all of "Subject", "Summary" and "Body" to get the same information? it would be quicker, i suppose ... d From phelps at dstc.edu.au Thu Jul 18 20:09:52 2002 From: phelps at dstc.edu.au (Ted Phelps) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Merging chat and news messages? In-Reply-To: <20020711090826.GA23725@magnetic-ink.dk> Message-ID: <200207181009.g6IA9jpq011049@dstc.edu.au> Klaus Alexander Seistrup may have said: > I was under the impression that the org.tickertape.message v2.0 was > supposed to merge chat and news messages into a unified message > format - a step that I welcome, since it somehow simplifies the > writing of client implementations. I'm afraid that I'm not particularly keen on this idea. From my point of view, the format of a notification should not be bent, folded or mutilated in order to accomodate a particular consumer. There's a tendency to make every notification into a tickertape notification because that's the only UI we have, and this feels like an extreme case of that tendency. I'm not at all happy with the idea of a chat message having a "Subject" field. my 2p, -Ted From philc at itee.uq.edu.au Fri Jul 19 13:59:37 2002 From: philc at itee.uq.edu.au (Phil Cook) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Merging chat and news messages? In-Reply-To: <200207181009.g6IA9jpq011049@dstc.edu.au> Message-ID: <200207191401.44678.philc@itee.uq.edu.au> On Thursday 18 July 2002 08:09 pm, Ted Phelps wrote: > Klaus Alexander Seistrup may have said: > > I was under the impression that the org.tickertape.message v2.0 was > > supposed to merge chat and news messages into a unified message > > format - a step that I welcome, since it somehow simplifies the > > writing of client implementations. > > I'm afraid that I'm not particularly keen on this idea. > > From my point of view, the format of a notification should not be > bent, folded or mutilated in order to accomodate a particular > consumer. There's a tendency to make every notification into a > tickertape notification because that's the only UI we have, and this > feels like an extreme case of that tendency. I'm not at all happy > with the idea of a chat message having a "Subject" field. I tend to agree with Ted here. Ted mentioned at the Ticker workshop last year that he wanted to develop a language for transforming notifications in xtickertape. I think this is the better route to take, and would also help to avoid the "tendency to make every notification into a tickertape notification". If we've only got one UI, then we should make that UI flexible enough to handle a wide range of notification formats. A notification transformation language would also complement the subscription language by further reducing the coupling between producers and consumers. Consumers that are flexible enough to subscribe to a wide range of notifications (as many of the tickertape clients now are) should be flexible enough to do something useful with those notifications. Any consumer that allows the user to specify an arbitrary subscription string, arguably, is incomplete if it doesn't let the user specify what to do with notifications that match that subscription. So I propose we give some more thought to such a transformation language, and attempt to develop a library consumers can use to get at it. Phil. _____________________________________________________________________________ Phil Cook "No Neil, after you" Ph.D. student at large - Buzz Aldrin School of Information Technology and Electrical Engineering The University of Queensland, QLD, 4072, Australia From Matthew.Phillips at dsto.defence.gov.au Fri Jul 19 15:12:46 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Merging chat and news messages? Message-ID: <108E7D907871D6118B5000306E0189F8A67019@ednex504.dsto.defence.gov.au> I have to agree that "Subject" just feels wrong as the "Message" for chat messages. I guess the general motivation here is that, since chat and news are such similar things, It Would Be Bice If (tm) we could use exactly the same base fields for both and that clients wouldn't have to care about the difference if they didn't want to. But if that can't be done cleanly (and it appears it can't), then I agree we should accept that chat messages only have a Message field, news messages have a Subject and Message field, and it's up to ticker clients to deal with displaying a news messages' Subject in the tickertape and a chat messages' Message. My 2.2c (incl GST) Cheers, Matthew. > -----Original Message----- > From: Phil Cook [mailto:philc@itee.uq.edu.au] > Sent: Friday, 19 July 2002 1:32 PM > To: Ted Phelps; ticker-dev@dstc.edu.au > Subject: Re: [ticker-dev] Merging chat and news messages? > > > On Thursday 18 July 2002 08:09 pm, Ted Phelps wrote: > > Klaus Alexander Seistrup may have said: > > > I was under the impression that the > org.tickertape.message v2.0 was > > > supposed to merge chat and news messages into a unified message > > > format - a step that I welcome, since it somehow simplifies the > > > writing of client implementations. > > > > I'm afraid that I'm not particularly keen on this idea. > > > > From my point of view, the format of a notification should not be > > bent, folded or mutilated in order to accomodate a particular > > consumer. There's a tendency to make every notification into a > > tickertape notification because that's the only UI we have, and this > > feels like an extreme case of that tendency. I'm not at all happy > > with the idea of a chat message having a "Subject" field. > > I tend to agree with Ted here. Ted mentioned at the Ticker > workshop last year > that he wanted to develop a language for transforming > notifications in > xtickertape. I think this is the better route to take, and > would also help > to avoid the "tendency to make every notification into a tickertape > notification". If we've only got one UI, then we should make that UI > flexible enough to handle a wide range of notification formats. > > A notification transformation language would also complement > the subscription > language by further reducing the coupling between producers > and consumers. > Consumers that are flexible enough to subscribe to a wide range of > notifications (as many of the tickertape clients now are) > should be flexible > enough to do something useful with those notifications. Any > consumer that > allows the user to specify an arbitrary subscription string, > arguably, is > incomplete if it doesn't let the user specify what to do with > notifications > that match that subscription. > > So I propose we give some more thought to such a > transformation language, and > attempt to develop a library consumers can use to get at it. > > Phil. > ______________________________________________________________ > _______________ > Phil Cook "No > Neil, after you" > Ph.D. student at large > - Buzz Aldrin > School of Information Technology and Electrical Engineering > The University of Queensland, QLD, 4072, Australia > From Must_Book at address.com Mon Jul 22 05:52:34 2002 From: Must_Book at address.com (Dr. Carter) Date: Tue Oct 14 08:01:42 2003 Subject: An easy & great contribution to yourself, family, neighborhood and society Message-ID: <4168-220027021195235900@oemcomputer> Dear Sir/Ma'am: It is significantly beneficial to your local (public, private, school, college, institutional, or ...) library and its patrons to have a book titled "Complete Conduct Principles for the 21st Century" by Dr. John Newton. Please kindly suggest to your local library(ies) that the book be purchased. This is an easy but GREAT & respectable contribution you can make to yourself, your family, neighborhood and society! "I find it heartening that you are crusading on behalf of this worthy book. It has occupied a space on our shelves for some time now. To have this book in our library is a quiet source of pride to me, the librarian." said Mr. Don Brusha, a highly respectable Librarian of Avon Park Library in Avon Park, Florida, USA, in a letter to me regarding the book. This book is a MUST for EVERYONE to be better prepared for personal conduct for the 21st century. EVERY LIBRARY SHOULD HAVE IT. You may ask yourself > How to make people respect you > How to win friends > How to let your conduct help your health, work, job, career, relationships, spirit, mind, well-being, ... > How to make your life smoother and happier > How to do whatever you like without being unpleasant to other people > How to develop good conduct in your children or students > How to make the world peaceful and better You (and the library patrons) can find all the answers to these questions, and much more, in this great book. BENEFITS to each individual reader: Many! -- such as for health, work, job, career, self-improvement, education, relationships, spirit, mind, well-being, and much more -- almost all the areas that are important to you in the 21st century. People around you will benefit, too. (Please see the preface of the book for details.) EVERYONE may find this book useful and helpful, regardless of age (from children to oldsters), occupation, rank, status, gender, religious beliefs, nationality, country, or region. If you are a parent or a teacher, you can learn how to develop good conduct in your children or students from this book. Please advise your children or students to read the book. It will result in great benefits for both you and them. The book's content is obvious from its title. The complete useful conduct principles cover not only what we should do, but also what we should not do -- especially those faults people make often and easily. "The book will also be effective for violence prevention for the whole society." said some experts. This timely, unique, and very important book is designed to suit most people, and is self-contained and user-friendly. This book is significantly different and better than competitive works. Some of its innovative contents may help solve problems that Western culture cannot. The book's merit and importance have been recognized and praised by many experts, elected public officials, and world leaders. How to make the world peaceful and better --- You (and the library patrons) can find the solution in the book. Let's work together to make the world peaceful and better! The author, John Newton, holds a Ph.D. from MIT, and does researches at Harvard. His long-term research on "The personal conduct in the human society of the 21st century" resulted in this book. It is published by Nicer Century World Organization, headquartered beside Harvard University and MIT, two leading institutes of new knowledge and literature. It has the Library of Congress Cataloging-in-Publication data. Hardcover (case bound, Smyth sewn; with dust jacket) ISBN 0967370574 Paperback (perfect bound) ISBN 0967370582 Bound durably and functionally to stand up to heavy library use. 60 lb natural acid-free excellent and healthful paper. 5.5inX8.5in. 192 pages. Including Principle Index and General Index. Self-contained. ------------------------------------------------ If you are personally interested in more information about the availability of the book and wish to request an Internet link, this section (within ---- signs) is for you. Otherwise you may skip this section. The book is available from many fine on-line bookstores, traditional bookstores, book wholesalers, book dealers, etc. For your convenience, I herewith provide you with a link directly to the book page in the shopping directory of Yahoo!, the world's No. 1 Internet directory (Some bookstores there offer great discounts [for a limited time]): http://shopping.yahoo.com/shop?d=b&id=1967680641&cf=setup ------------------------------------------------- Again, please kindly suggest to your local library(ies) that the book be purchased. Also, please kindly forward this e-mail to people you know. Your effort to make a GREAT and respectable contribution to yourself, to your family and neighborhood, to people you know, and to the whole society will be highly appreciated. Sincerely yours, Tom Carter, Ph.D. President, Nicer Century World Organization Massachusetts, USA (Nicer Century World Organization is an educational, non-profit, non-partisan organization; it endeavors to make the 21st century nicer than ever before. To accomplish its mission, Nicer Century World Organization is proud to introduce this book.) From scott at dstc.edu.au Tue Jul 30 16:07:12 2002 From: scott at dstc.edu.au (Scott Harris) Date: Tue Oct 14 08:01:42 2003 Subject: Ticker sugestion Message-ID: Heya, (Ted?) Suggestion for ticker : make channel names case insensitive. The idea that "beer" and "Beer" are 2 distinct channels is inherently broken imho. Just a thought. Idea even :-) -Scott From mjh at dstc.edu.au Tue Jul 30 16:12:14 2002 From: mjh at dstc.edu.au (Michael Henderson) Date: Tue Oct 14 08:01:42 2003 Subject: Ticker suggestion (fwd) Message-ID: ---------- Forwarded message ---------- From: Scott Harris To: ticker-dev@dstc.edu.au Subject: Ticker sugestion Heya, (Ted?) Suggestion for ticker : make channel names case insensitive. The idea that "beer" and "Beer" are 2 distinct channels is inherently broken imho. Just a thought. Idea even :-) -Scott From julian at dstc.monash.edu.au Thu Aug 15 10:36:40 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:42 2003 Subject: Why Attachment field as byte array? Message-ID: <200208150013.g7F0DIk03585@xevious.dstc.monash.edu.au> The Attachment field in the latest ticker spec (3.0) is defined as a byte array. Attachment opaque A MIME-encoded addition to the message. Multiple attached objects SHOULD be encoded using the multipart/mixed MIME type. Note that this field is an opaque type, and thus an array of bytes. therefore, it is not necessary to transform attachments (using, for example, base64) as is the usual practice for email. However, it is also MIME encoded. Given that MIME is intended to support sending binary information as text, is there any reason I am missing why the Attachment filed should not be defined as being a string? I must admit that my knowledge of MIME is user level, not implementaion level... For instance, if an application receives and Attachment in a notif, how does it determine if its a MIME string, or a binary JPEG? Or is that just part of the magic MIME handlers are expected to cope with? -J ---- julian boot ))X(( senior research scientist elvin http://elvin.dstc.com From julian at dstc.edu.au Thu Aug 15 10:38:05 2002 From: julian at dstc.edu.au (Julian Boot) Date: Tue Oct 14 08:01:42 2003 Subject: Why Attachment as byte array? Message-ID: <200208150038.g7F0c5h7020223@piglet.dstc.edu.au> The Attachment field in the latest ticker spec (3.0) is defined as a byte array. Attachment opaque A MIME-encoded addition to the message. Multiple attached objects SHOULD be encoded using the multipart/mixed MIME type. Note that this field is an opaque type, and thus an array of bytes. therefore, it is not necessary to transform attachments (using, for example, base64) as is the usual practice for email. However, it is also MIME encoded. Given that MIME is intended to support sending binary information as text, is there any reason I am missing why the Attachment filed should not be defined as being a string? I must admit that my knowledge of MIME is user level, not implementaion level... For instance, if an application receives and Attachment in a notif, how does it determine if its a MIME string, or a binary JPEG? Or is that just part of the magic MIME handlers are expected to cope with? -J ---- julian boot ))X(( senior research scientist elvin http://elvin.dstc.edu.au From j at pobox.com Thu Aug 15 10:41:30 2002 From: j at pobox.com (j@pobox.com) Date: Tue Oct 14 08:01:42 2003 Subject: Why Attachment field as byte array? In-Reply-To: Message-ID: <200208150018.g7F0I8k03620@xevious.dstc.monash.edu.au> The Attachment field in the latest ticker spec (3.0) is defined as a byte array. Attachment opaque A MIME-encoded addition to the message. Multiple attached objects SHOULD be encoded using the multipart/mixed MIME type. Note that this field is an opaque type, and thus an array of bytes. therefore, it is not necessary to transform attachments (using, for example, base64) as is the usual practice for email. However, it is also MIME encoded. Given that MIME is intended to support sending binary information as text, is there any reason I am missing why the Attachment filed should not be defined as being a string? I must admit that my knowledge of MIME is user level, not implementaion level... For instance, if an application receives and Attachment in a notif, how does it determine if its a MIME string, or a binary JPEG? Or is that just part of the magic MIME handlers are expected to cope with? -J ---- julian boot ))X(( senior research scientist elvin http://elvin.dstc.com From arnold at dstc.monash.edu.au Thu Aug 15 11:03:45 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: Message-ID: <200208150040.g7F0eNk03741@xevious.dstc.monash.edu.au> -->"j" == j writes: j> The Attachment field in the latest ticker spec (3.0) is defined j> as a byte array. yep. j> Note that this field is an opaque type, and thus an array of j> bytes. therefore, it is not necessary to transform attachments j> (using, for example, base64) as is the usual practice for email. in other words, you are free to use 8bit encoding, and there is no need for base64 or any other mechanism to ensure the entire object is 7bit clean. j> However, it is also MIME encoded. the MIME encoding is used to describe the type of the enclosed object(s) in a way that it was hoped would be reasonably portable. it also allows for transparent attachment of multiple objects. j> Given that MIME is intended to support sending binary information j> as text, is there any reason I am missing why the Attachment j> filed should not be defined as being a string? this was the hardest choice. opaque has some forcing function for attachment vs. content, which highlights the blurring between these roles in current practice. opaque removes the need to use base64 (or other) encoding for content data. string means that everything has to be 7bit clean (or it risks collision with UTF-8 rules). string allows matching over the MIME *headers*, using contains()/wildcard()/regex(). this maintains the blurring between content and attachment we currently have. allowing matching over attachment fields is potentially expensive, performance-wise, when attachments could be quite large. j> For instance, if an application receives and Attachment in a j> notif, how does it determine if its a MIME string, or a binary j> JPEG? Or is that just part of the magic MIME handlers are j> expected to cope with? it MUST be a MIME object. to attachment a JPEG, the image data needs to be wrapped in MIME headers, something like MIME-Version: 1.0 Content-Type: image/jpeg; name="pr0n.jpg" Content-Disposition: attachment; name="pr0n.jog" Content-Transfer-Encoding: 8bit < image data > it it not legal to attach plain content (without MIME headers). d From Matthew.Phillips at dsto.defence.gov.au Thu Aug 15 14:50:34 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: Key exchange In-Reply-To: Message-ID: <108E7D907871D6118B5000306E0189F8A67076@ednex504.dsto.defence.gov.au> Hi all, I've been looking at the import/export of keys for secure notifications so we can easily get the various ticker clients talking clandestinely to each other. My travels through crypto-land indicate that there are standard formats for keys such as PKCS12 that not only allow key export, but also certificate chains the validate the keys (ie signed keys). However, none of the key types supported (such as DSA or DER) include the SHA1 key pairs that Elvin uses (presumably because this way of generating key pairs is not useful in a "real" asymmetric crypto algorithm). So I'm going to propose a simple format for key exchange in the meantime. An example: ---------- BEGIN ELVIN KEY ---------- Name: DSTO Private Key Type: PRIVATE Value: DEADBEEF1234567890CAFEBABEETCETCETCETCETCETCETC ---------- END ELVIN KEY ---------- Name is the mnemonic name of the key (clients should try to preserve it, but it doesn't affect the key itself). Type is either "PRIVATE" or "PUBLIC" - should be self-explanatory Value: Is the hex-encoded value of the key. Comments? Matthew. From philc at itee.uq.edu.au Thu Aug 15 15:14:35 2002 From: philc at itee.uq.edu.au (Phil Cook) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Key exchange In-Reply-To: <108E7D907871D6118B5000306E0189F8A67076@ednex504.dsto.defence.gov.au> Message-ID: <200208151517.53303.philc@itee.uq.edu.au> On Thursday 15 August 2002 02:41 pm, Phillips, Matthew wrote: > Value: Is the hex-encoded value of the key. What about base64? Phil. From arnold at dstc.monash.edu.au Thu Aug 15 15:58:55 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Key exchange In-Reply-To: <108E7D907871D6118B5000306E0189F8A67076@ednex504.dsto.defence.gov.au> Message-ID: <200208150535.g7F5ZVk04885@xevious.dstc.monash.edu.au> -->"Matthew" == Phillips, Matthew writes: Hi Matthew, Matthew> My travels through crypto-land indicate that there are Matthew> standard formats for keys such as PKCS12 that not only Matthew> allow key export, but also certificate chains the validate Matthew> the keys (ie signed keys). do you have a recommended reference for this standard? Matthew> However, none of the key types supported (such as DSA or Matthew> DER) include the SHA1 key pairs that Elvin uses (presumably Matthew> because this way of generating key pairs is not useful in a Matthew> "real" asymmetric crypto algorithm). i'd guess that's the case too. it's a different mechanism altogether. Matthew> So I'm going to propose a simple format for key exchange in Matthew> the meantime. ---------- BEGIN ELVIN KEY ---------- Name: DSTO Private Key Type: PRIVATE Value: DEADBEEF1234567890CAFEBABEETCETCETCETCETCETCETC ---------- END ELVIN KEY ---------- Matthew> Comments? you might like to check out this thread http://www.elvin.biz/ListArchive/elvin-dev/archive/2001/09/msg00033.html i'll have some more details comments later, but it seems quite close to what julian and i had proposed ... d From Matthew.Phillips at dsto.defence.gov.au Thu Aug 15 17:00:43 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Key exchange In-Reply-To: Message-ID: <108E7D907871D6118B5000306E0189F8A6707E@ednex504.dsto.defence.gov.au> Hi David, > -->"Matthew" == Phillips, Matthew > writes: > > Hi Matthew, > > Matthew> My travels through crypto-land indicate that there are > Matthew> standard formats for keys such as PKCS12 that not only > Matthew> allow key export, but also certificate chains the validate > Matthew> the keys (ie signed keys). > > do you have a recommended reference for this standard? Hehe, my great knowledge of PKI crypto standards comes from simply reading the Java Crypto Extensions (JCE) docs. See the architecture doc http://java.sun.com/j2se/1.4/docs/guide/security/CryptoSpec.html and the reference guide http://java.sun.com/j2se/1.4/docs/guide/security/jce/JCERefGuide.html. The PKCS standards come from RSA (eg http://www.rsasecurity.com/rsalabs/pkcs/pkcs-8/) and seem to be widely used (eg SSL). I actually think using one of these would be overkill unless we want to use digital signatures to transfer keys across open channels. > you might like to check out this thread > > http://www.elvin.biz/ListArchive/elvin-dev/archive/2001/09/msg00033.html Wow, the format there is spookily similar. I'd be happy to follow that, although I would agree with Ian that a simple "Shared"/"Private" would suffice over specifying consumer/producer/dual as well as access (I certainly intend in Sticker to KISS and simply distinguish between shared/private keys and use the "Ian" algorithm to determine where they get used). Matthew. From ilister at dstc.edu.au Thu Aug 15 17:45:28 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:42 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: Message-ID: On Thu, 15 Aug 2002, David Arnold wrote: >-->"j" == j writes: > j> Given that MIME is intended to support sending binary information > j> as text, is there any reason I am missing why the Attachment > j> filed should not be defined as being a string? > >this was the hardest choice. [snipped pros and cons] What about allowing it to be either an opaque or a string (but still forbidding any encodings that aren't currently allowed)? That way simple stuff can still be dealt with simply, and is available to be routed on. Ian From arnold at dstc.monash.edu.au Thu Aug 15 19:04:27 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: Message-ID: <200208150841.g7F8f3k05903@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> What about allowing it to be either an opaque or a string (but Ian> still forbidding any encodings that aren't currently allowed)? there're no encoding forbidden now, it's just that they're not necessary? Ian> That way simple stuff can still be dealt with simply, and is Ian> available to be routed on. i worry about contains(Attachment, "x-elvin/url") being evaluated over images and Word files. it's gonna chew a lot of CPU. making it opaque prevents this nicely, and makes people route on the "content" (as distinct from the attachment). but does it break people's usage? d ob-lawley: if elvin had structured notifications, a better solution would use a list of hashes to make the content type (at least) available for routing (and possibly the data for some content types) From ilister at dstc.edu.au Thu Aug 15 19:33:53 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: <200208150841.g7F8f3k05903@xevious.dstc.monash.edu.au> Message-ID: On Thu, 15 Aug 2002, David Arnold wrote: >-->"Ian" == Ian Lister writes: > Ian> What about allowing it to be either an opaque or a string (but > Ian> still forbidding any encodings that aren't currently allowed)? > >there're no encoding forbidden now, it's just that they're not >necessary? Oh, OK, I wasn't sure (which was why I carefully phrased my sentence to still be technically correct even if that was the case ;-) >i worry about > > contains(Attachment, "x-elvin/url") > >being evaluated over images and Word files. it's gonna chew a lot of >CPU. making it opaque prevents this nicely, and makes people route on >the "content" (as distinct from the attachment). A producer attaching a binary file can still use the opaque type. This seems like a drastic limitation on common use for the benefit of (currently) rather uncommon use. I'm not sure it's a good idea to go out of our way to stop people routing on particular parts of the content (and I think the attachment is still part of the content, even if the name makes it sound less important). It also goes to show that bundling all the MIME stuff into a single attribute is not optimal for content based routing. It's really quite similar to throwing an XML document into a single attribute; it makes it hard to match on the logical elements that are a part of that attribute. >but does it break people's usage? Currently people route on channels, and that's just about it. I can think of lots of cool things to do with routing on the attachment content, and maybe nobody will ever implement them, but they certainly won't be able to if it's opaque. Ian From julian at dstc.monash.edu.au Thu Aug 15 19:34:56 2002 From: julian at dstc.monash.edu.au (Julian Boot) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: <200208150841.g7F8f3k05903@xevious.dstc.monash.edu.au> Message-ID: <200208150911.g7F9BVk06036@xevious.dstc.monash.edu.au> David Arnold wrote: > ob-lawley: > if elvin had structured notifications, a better solution would use a > list of hashes to make the content type (at least) available for > routing (and possibly the data for some content types) It funny you should mention that, lawley, because the 1 hour hack I did this morning for my client adds Attachment-Header-Field items to the notif when it arrives; maybe for debug right now, but I probably won't remove it anytime soon ... -J From j at pobox.com Thu Aug 15 19:48:54 2002 From: j at pobox.com (j@pobox.com) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: Message-ID: <200208150925.g7F9PUk06122@xevious.dstc.monash.edu.au> David Arnold wrote: > ob-lawley: > if elvin had structured notifications, a better solution would use a > list of hashes to make the content type (at least) available for > routing (and possibly the data for some content types) It funny you should mention that, lawley, because the 1 hour hack I did this morning for my client adds Attachment-Header-Field items to the notif when it arrives; mostly for debug right now, but I probably won't remove it anytime soon ... -J From lawley at dstc.edu.au Mon Aug 19 13:38:11 2002 From: lawley at dstc.edu.au (Michael Lawley) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] Why Attachment field as byte array? In-Reply-To: Message-ID: <200208190338.g7J3cB4O011350@piglet.dstc.edu.au> David Arnold wrote: > ob-lawley: > if elvin had structured notifications, a better solution would use a > list of hashes to make the content type (at least) available for > routing (and possibly the data for some content types) Couldn't have said it better myself...oh |v| "analog - the new digital" -- Michael Lawley, http://purl.org/NET/lawley Scientician. From martin.wanicki at boeing.com Mon Aug 26 10:59:51 2002 From: martin.wanicki at boeing.com (I-Wanicki, Martin) Date: Tue Oct 14 08:01:43 2003 Subject: org.tickertape.message 3x - Thread-Id In-Reply-To: Message-ID: <21BEC9503B89D111A8F700805FE6A3690D682C7E@xch-bne-01.bal.bna.boeing.com> Suggest change to the following description in spec 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 messages with this Thread-Id value). User agents, receiving a message with a Thread-Id set, SHOULD copy the supplied value into the same-named attribute of any reply messages. This value must be globally unique. See Message-Id for recommendations. This description does not seem to suggest the use of this field The notion of thread-based manipulations like, but not limited to thread blocking is not mentioned - as such since these types of manipulations seem to be becoming part of a few clients, interoperability would almost demand this field to be set at all times. The ides of use seems to be New 'ROOT' messages are the beginning of a new thread therefor its would seem to be legal to set the Thread-Id to the Message-Id of the new outgoing message. Since it is mandatory to copy the incoming Thread-id to the outgoing Thread-Id in all reply messages I suggest this field become mandatory for tickertape messages. here's my suggestion ... Thread-Id string This field should be populated at all times User agents, receiving a message with a Thread-Id set, SHOULD copy the supplied value into the same-named attribute of any reply messages. User agents, sending a new message which is NOT a reply, SHOULD copy the Message-Id from the notification about to be sent into the same-named attribute of the notification about to be sent. 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 messages with this Thread-Id value). This value must be globally unique. See Message-Id for recommendations. Over to the ticker-dev(otee's) Cheers martin From arnold at dstc.monash.edu.au Wed Oct 2 15:36:19 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: ticker attachments (again) In-Reply-To: Message-ID: <200210020506.g9256Nk06069@xevious.dstc.monash.edu.au> in ticker conversation today, Ian has proposed that the draft ticker v3 spec be revised, renaming "Attachment" to "MIME-Attachment". it's my impression (please correct me if i'm wrong, Ian) that the motivation is to facilitate transition to alternative forms of attachment in future, should that be required. in particular, the use of (the oft-proposed) structured notifications to represent the nested attributes of an attachment might be possible in future Elvin revisions. additionally, the use of a monolithic MIME attachment is controversial (to say the least :-) which IMO also argues for facilitation of later replacement. are there any objections to this change? d From ilister at dstc.edu.au Wed Oct 2 16:33:35 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] ticker attachments (again) In-Reply-To: Message-ID: On Wed, 2 Oct 2002, David Arnold wrote: >in ticker conversation today, Ian has proposed that the draft ticker >v3 spec be revised, renaming "Attachment" to "MIME-Attachment". For the record it was only a tentative suggestion, which I decided wasn't worth persuing following subsequent conversation, but... :-) >it's my impression (please correct me if i'm wrong, Ian) that the >motivation is to facilitate transition to alternative forms of >attachment in future, should that be required. The motivation was more an idea that content routed data is more useful the more it can be interpreted in its own context i.e. without dependence on the context of the producer, consumer or protocol the notification is supposed to conform to. This requires applications to use attribute names that are consistent between applications. The name isn't necessarily important - we could call it `Foo' if all applications (not just Tickertape) consistently used that name for attached MIME data - but it seems that having a reasonably unambigous name that clearly describes the nature of the value can only help. >in particular, the use of (the oft-proposed) structured notifications >to represent the nested attributes of an attachment might be possible >in future Elvin revisions. That is certainly an issue to consider but I am happy we can use MIME-Version, MIME-Type, etc as attribute names (or sub-names) if we break the MIME data apart into separately addressable named components (attributes). >additionally, the use of a monolithic MIME attachment is controversial >(to say the least :-) which IMO also argues for facilitation of later >replacement. Facilitation of later replacement is good :-) Ian From arnold at dstc.monash.edu.au Wed Oct 2 17:18:48 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] ticker attachments (again) In-Reply-To: Message-ID: <200210020648.g926mpk06690@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> That is certainly an issue to consider but I am happy we can Ian> use MIME-Version, MIME-Type, etc as attribute names (or Ian> sub-names) if we break the MIME data apart into separately Ian> addressable named components (attributes). i'd be reluctant to use the word MIME to describe components of a structured attachment mechanism (with the possible exception of the type field?) since it would not be at all compatible with genuine MIME-encoded data. but this is good -- it distinguishes the current mechanism. naming the field "MIME-Attachment" is reasonably concise, and yet (i think) suitably unambiguous. d From ilister at dstc.edu.au Wed Oct 2 17:27:04 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] ticker attachments (again) In-Reply-To: <200210020648.g926mpk06690@xevious.dstc.monash.edu.au> Message-ID: On Wed, 2 Oct 2002, David Arnold wrote: >i'd be reluctant to use the word MIME to describe components of a >structured attachment mechanism (with the possible exception of the >type field?) since it would not be at all compatible with genuine >MIME-encoded data. We can argue about it when it becomes an issue, but I think it's OK given that the data has the structure of MIME (even if it is not serialised as MIME is) and that the name refers to a component of what would be in the MIME stream. >but this is good -- it distinguishes the current mechanism. naming >the field "MIME-Attachment" is reasonably concise, and yet (i think) >suitably unambiguous. Good - that was the intention :-) Ian From kathy.bradley at mail.internetseer.com Sun Oct 6 11:29:02 2002 From: kathy.bradley at mail.internetseer.com (Kathy Bradley) Date: Tue Oct 14 08:01:43 2003 Subject: Error accessing your website Message-ID: <16369714.1033867586275.JavaMail.promon@pm68> On Sat Oct 05, 2002 at 12:19:27 PM EDT I was unable to reach your web site: http://elvin.dstc.com/community/mail.html due to the following error: Host Not Found As of Sat Oct 05, 2002 at 09:28:55 PM EDT I am able to access your web site again. I work for InternetSeer, a Web site monitoring company. InternetSeer is conducting an ongoing study of web connectivity. As recommended by the Robots Guidelines, this email is being sent to explain our research activities and to let you know about the difficulty in connecting to your site. The error listed above was initially detected by our primary site monitor in Philadelphia, Pa. then verified by our secondary site monitor located in Los Angeles, Ca. before this error event was recorded. InternetSeer is the largest FREE web site monitoring company in the world. We provide free web site monitoring to over 1 million users worldwide. We'll monitor your web site 7 days a week, 24 hours a day - for free. To have InternetSeer monitor your web site for free, click here for instant signup. To learn more about our FREE service before signing up click here. As part of your free web site monitoring service, you'll receive immediate notifications when we encounter problems accessing your web site and weekly performance reports. There is no need to cancel because InternetSeer will never contact you again at this email address: ticker-dev@dstc.edu.au. If you have other email addresses that you would like excluded from any potential future contact, click here to have those email addresses excluded from our system. InternetSeer does not store or publish the content of your pages, but rather uses availability and link information for our research.Click here to learn more about InternetSeer. Sincerely, Kathy Bradley Web Site Analyst InternetSeer.com As stated above, there is no need to cancel since YOU WILL NEVER be contacted again at ticker-dev@dstc.edu.au, but you may click here for a removal confirmation from our web site. ##ticker-dev@dstc.edu.au## SRC="53 From ilister at dstc.edu.au Mon Oct 7 13:39:34 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: My design objectives with Tickertape In-Reply-To: Message-ID: In some of the recent discussions about Tickertape v3 (specifically most recently the structure of attachments) it seems that various people have been looking at it from differing viewpoints, with apparently slightly different design goals. I thought it might be useful if I explained where I'm coming from. I see three major potential areas of Tickertape's value: 1. As a commercial product This isn't the best forum for talking about commercial issues, but I don't think commercialisation of Tickertape is a current major goal. 2. As a useful collaboration tool Obviously we all use Tickertape for day-to-day communication so things that are of practical use are important. This is also very compatible with (1) above. 3. As an example Elvin application This is probably the most contentious goal i.e. one that others may not share. This includes examples of best practice in particular areas of Elvin application design e.g. attribute naming (this is the only justification I can see for changing attribute names in v3) and design to best show off Elvin's unique features such as the security mechanism, content based routing, decoupling of components, and flexible design to allow compatible future use in ways not thought of when the application was first designed. Tickertape may not be the ideal basis for this given its strong (but not necessarily total) channel orientation, but I think it's far and away the best example we have. I see (2) and (3) as important (assuming nobody tells me to prioritise (1)), not so that (3) should ever be focussed on at the expense of (2), but neither so that (3) should be ignored just for the purposes of (2). FYI, FWIW, YMMV, etc Ian From arnold at dstc.monash.edu.au Mon Oct 7 19:24:12 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] My design objectives with Tickertape In-Reply-To: Message-ID: <200210070853.g978rXk09413@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: Ian> This is probably the most contentious goal i.e. one that Ian> others may not share. i don't personally consider either the tickertape protocol or the various bits of tickertape code to have demonstrating Elvin "best practice" as a design goal. of course, i would hope that tickertape (and tickertape programmers, administrators, users, etc) would find good elvin practices useful and beneficial. imo, where they (spec and code) depart from Elvin best practice, it should be because tickertape exists independently: it does not exist primarily as an example elvin program. i don't think this conflicts with your ranking of 2 and then 3, but i think perhaps i consider 3 (being a good elvin demo) at a (much?) lower priority? Ian> This includes examples of best practice in particular areas of Ian> Elvin application design e.g. attribute naming (this is the Ian> only justification I can see for changing attribute names in Ian> v3) i attempted to change the naming in the 2.0 spec (which sticker alone adopted), and again for 3.0, basically because i wanted to do it asap and in particular before the hideous ugliness of ALL_CAPS became entrenched forever. imo (and i suppose that had a bit to do with it :-), it is not a matter of demonstrating best naming practice, but rather allowing tickertape programmers to have the benefits of a consistent and aesthetically-tolerable specification with which to work. but the motivation was not to demonstrate Elvin goodness, but to have tickertape profit from the goodness. Ian> Tickertape may not be the ideal basis for this given its strong Ian> (but not necessarily total) channel orientation, but I think Ian> it's far and away the best example we have. which is unfortunate. i think ticker deserves a life of its own. ticker should do things the Tickertape Way (TM). and naturally, that will overlap a lot with the Elvin Way, given that many of the protagonists are the same, but i think there are times when we tend to make the middleware drive the user experience, and i hope to minimise them. how does that gel with making attachments opaque at least partially so that routers don't have to handle string ops on word documents? that's probably another discussion. in short though, it's not my only motivation. while i'm concerned with the implementation issues, i think i'm mostly interested in distinguishing between attachments (which can be opaque) and the message (which cannot). if there is a user requirement for subscribe-able rich content, then i wonder if we shouldn't be addressing that issue, rather than mucking around with bolting it on the side as attachments? but that's a tickertape-4.0 discussion ... Ian> I see (2) and (3) as important (assuming nobody tells me to Ian> prioritise (1)), not so that (3) should ever be focussed on at Ian> the expense of (2), but neither so that (3) should be ignored Ian> just for the purposes of (2). i think perhaps we diverge here: i would happily sacrifice 3 (being a good example of an elvin program) if it impinged on 2 (being a good tickertape (whatever that really is)). Ian> FYI, FWIW, YMMV, etc interesting topic. it might be interesting to articulate what makes ticker good (and better than ICQ/AIM/Jabber/IRC/ytalk) as a statement of goals. or it might just be devisive and pointless. Geraldine's (and Donaugh's) contribution was to make this sort of observation from the sidelines, allowing us to adopt or not, as we felt fit. and she came from a Tickertape perspective, not Elvin. i think i miss that more than i knew. d From martin.wanicki at boeing.com Tue Oct 8 11:38:43 2002 From: martin.wanicki at boeing.com (I-Wanicki, Martin) Date: Tue Oct 14 08:01:43 2003 Subject: V3.0 Of the tickertape notification format specification - attachments and a suggested addition... Message-ID: <21BEC9503B89D111A8F700805FE6A3690DE88AA2@xch-bne-01.bal.bna.boeing.com> Dear all, The recent discussion about the Attachment field and mime types brought about (in my mind) an scenario/alternative/addition (take your pick) that may seem reasonable to Tickertape developers. The use of the attachment field at this point in time seems to be predominately for passing url's around. After some research I have come to the conclusion the url's have a completely encapsulated specification ( http://www.ietf.org/rfc/rfc1738.txt ) that need not be wrapped in yet another specification (i.e. mime) The url protocol seems to function without mime perfectly well and as such I propose the addition of an optional attribute for the purpose of passing url's. A possible name for this might just be Url: or Hyperlink: or whatever name on which a reasonable consensus can be reached. Regarding backward compatibility issues, the old MIME_ARGS attribute *may* be considered equivalent since it has been predominately used for url's. The old (v2) supporting mime fields (MIME_TYPE and MIME_ENCODING) could reasonably be ignored or perhaps MIME_TYPE could be inspected to see if the MIME_ARGS are likely to contain a url. I'm not sure how other O.S's handle protocols but Microsoft Windows O.S's have clearly defined methods to handle existing protocols and introduce new handlers for new protocols ( http://msdn.microsoft.com/workshop/networking/pluggable/overview/appendix_a. asp?frame=true ) All of this would seem to reduce unnecessary re-encapsulation of url's within a mime document and also facilitate content based routing on url's. The only issue I can foresee that this proposal raises is that of multiple url's and what to do about supporting them in this scenario. Perhaps support for multiple url's should be moved to the mime attachment or perhaps we define the Url field as containing either one or more url's with a caveat on separation (i.e. at most one url per line of text) Regards, Martin From Matthew.Phillips at dsto.defence.gov.au Tue Oct 8 17:25:51 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] My design objectives with Tickertape Message-ID: <108E7D907871D6118B5000306E0189F8A67125@ednex504.dsto.defence.gov.au> > it might be interesting to articulate what makes ticker good (and > better than ICQ/AIM/Jabber/IRC/ytalk) as a statement of goals. or it > might just be devisive and pointless. This is a bit off-topic, but it's something that I've been pondering quite a bit lately: why do I feel that tickertape is better than/different to current instant messaging products? Right now there's a possibility that Elvin could be inserted into the Defence toolkit soley as a tickertape router, but why shouldn't I be recommending AIM or Lotus SameTime instead? Especially given that Defence already has a big investment in Lotus Notes, so SameTime would be a logical choice. So here's how tickertape beats IM from my point of view: (a) No sessions: it's "always on". You don't join a group, have a conversation in a window and then leave. You don't even need to join groups or know what groups might out there, you may be just picking message threads based on a filter expression (which is why I think Thread-Id is important). This makes tickertape as useful for broadcast alerts, news and enterprise instrumentation as it is for conversations between people. (b) Extensible: you can write a four line Python script to publish ticker messages. The other systems have big API's that worry about servers and logins and sessions and the many things that could go wrong establishing them. There's a lot of talk in Defence right now about "high tempo" operations ie reacting and adapting faster than the opponent. If you can safely and quickly add new info services in the field without installing infrastructure (mpossible in an operational environment) you can better adapt to unforseen needs and hence, hopefully, react faster. (c) Robust: not only can you easily setup failover servers, but you can rely on them working sensibly because there is no state on the server for tickertape or presence. Any other ammunition gratefully accepted ;) Cheers, Matthew. From mjh at dstc.edu.au Wed Oct 9 13:55:21 2002 From: mjh at dstc.edu.au (Michael Henderson) Date: Tue Oct 14 08:01:43 2003 Subject: V3.0 Of the tickertape notification format specification - attachmentsand a suggested addition... (fwd) In-Reply-To: Message-ID: ---------- Forwarded message ---------- From: "I-Wanicki, Martin" Dear all, The recent discussion about the Attachment field and mime types brought about (in my mind) an scenario/alternative/addition (take your pick) that may seem reasonable to Tickertape developers. The use of the attachment field at this point in time seems to be predominately for passing url's around. After some research I have come to the conclusion the url's have a completely encapsulated specification ( http://www.ietf.org/rfc/rfc1738.txt ) that need not be wrapped in yet another specification (i.e. mime) The url protocol seems to function without mime perfectly well and as such I propose the addition of an optional attribute for the purpose of passing url's. A possible name for this might just be Url: or Hyperlink: or whatever name on which a reasonable consensus can be reached. Regarding backward compatibility issues, the old MIME_ARGS attribute *may* be considered equivalent since it has been predominately used for url's. The old (v2) supporting mime fields (MIME_TYPE and MIME_ENCODING) could reasonably be ignored or perhaps MIME_TYPE could be inspected to see if the MIME_ARGS are likely to contain a url. I'm not sure how other O.S's handle protocols but Microsoft Windows O.S's have clearly defined methods to handle existing protocols and introduce new handlers for new protocols ( http://msdn.microsoft.com/workshop/networking/pluggable/overview/appendix_a. asp?frame=true ) All of this would seem to reduce unnecessary re-encapsulation of url's within a mime document and also facilitate content based routing on url's. The only issue I can foresee that this proposal raises is that of multiple url's and what to do about supporting them in this scenario. Perhaps support for multiple url's should be moved to the mime attachment or perhaps we define the Url field as containing either one or more url's with a caveat on separation (i.e. at most one url per line of text) Regards, Martin From arnold at dstc.monash.edu.au Wed Oct 9 15:06:03 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] V3.0 Of the tickertape notification format specification - attachments and a suggested addition... (fwd) In-Reply-To: Message-ID: <200210090435.g994ZAk23916@xevious.dstc.monash.edu.au> -->"Martin" == writes: Martin> The use of the attachment field at this point in time seems Martin> to be predominately for passing url's around. yes. that's all the majority of clients have supported until very recently. Martin> <...> I propose the addition of an optional attribute for Martin> the purpose of passing url's. A possible name for this might Martin> just be Url: or Hyperlink: or whatever name on which a Martin> reasonable consensus can be reached. this was briefly mentioned during ticker discussion the other day, but didn't seem to attract much attention. maybe it's a good half-way step between the 1.3 spec and a future spec with full attachment ability? or maybe MIME attachments is not something we really need/want? Martin> Regarding backward compatibility issues, the old MIME_ARGS Martin> attribute *may* be considered equivalent since it has been Martin> predominately used for url's. i'm happy to ignore backward compatibility :-) Martin> Perhaps support for multiple url's should be moved to the Martin> mime attachment or perhaps we define the Url field as Martin> containing either one or more url's with a caveat on Martin> separation (i.e. at most one url per line of text) i worry about usability issues in clients if we have multiple ways to attach things ... if we go for a separate mechanism for URL attachment, i'd be tempted to drop the MIME attachment for now. d From martin at wanicki.com Wed Oct 9 15:12:43 2002 From: martin at wanicki.com (Martin Wanicki) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] V3.0 Of the tickertape notification format specification - attachments and a suggested addition... (fwd) In-Reply-To: <21BEC9503B89D111A8F700805FE6A3690DE8921E@xch-bne-01.bal.bna.boeing.com> Message-ID: <004501c26f52$08160f20$bcb06682@banyan> David Arnold may have said >> > if we go for a separate mechanism for URL attachment, i'd be tempted > to drop the MIME attachment for now. No problem with that whatsoever, in fact - Yay! :-) Cheers Martin From arnold at dstc.monash.edu.au Wed Oct 9 15:39:00 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: ticker-ng Message-ID: <200210090508.g99586k24162@xevious.dstc.monash.edu.au> sometime in the late 90's, i wrote this proposal for a next-generation tickertape. it appears to be post-HTML, but pre-XML, which dates it somewhere in there :-) i thought i might as well share it ... ticker-ng ticker next generation is a derivative of the various tickertape programs developed following the original Python Tickertape. it alters the model substantially, moving from a fixed format message to a variable format controlled by a markup language. says: what about those lamers? hey?! the glyph that appears and is scrolled is described by a subscription. it refers to fields of the notification using the tag. just an annotation here, since this was really a description relying on a context not present (ie. my brain :-) the markup is a template, used to render notifications received because they match an associated subscription. so ticker 1.3 messages would have a template like : : or something like that. the scroller understands a limited set of MIME types which may be extended by plug-ins. like HTML, any tag which is not understood will be ignored by the ticker. an embedded object of type "text/x-tml" allows the notification to extend the markup (the content is included inline before further interpretation). on receiving a notification, the ticker program interprets the markup string, and generates a pixmap. the pixmap may have multiple areas sensitive to clicks (anchors). it is scrolled until removed. subscriptions can refer to any field of the event, in any format: there is no longer the need to extend ticker to understand different event types, nor to artificially munge events into a ticker format. the tag may also have a "default" attribute, used when the event does not have a field of the required name. this next bit is a little unclear. i *think* what this example meant was that you could create "hotspots" in the scrolling glyphs the would generate a reply -- the type is a MIME object that is created, with content as specified, and then handed to the system's MIME object interpreter, which i think this example presumes is a tickertape message editor. in addition to href anchors, a direct link is allowed, like "> or something like that it's not important, although if anyone were ever to implement something like this, i think this might be a more general mechanism than "href", which might be good. anyway -- hope someone finds this interesting, or even useful :-) d From arnold at dstc.monash.edu.au Thu Oct 10 17:11:52 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: new revision of ticker v3 spec Message-ID: <200210100640.g9A6eok03766@xevious.dstc.monash.edu.au> i've put a revised specification of the Tickertape v3 protocol on DSTC's FTP site for your comments ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-01.txt for reference, the previous draft remains at ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-00.txt changes in this revision: 1. "Replaces" is now a renamed "REPLACEMENT" with identical semantics. 2. attachments now use the "MIME-Attachment" attribute, rather than "Attachment", and are a string, not an opaque. this has been quite controversial, and i'm not sure that this is the best compromise. i'd encourage people to speak up if their needs are not met ... three outstanding issues remain from the first draft (replaces has been resolved). these are: security, the semantics of the Distribution attribute, and the lack of explanatory and motivational text. comments and contributions to any of those would be great :-) see http://elvin.dstc.edu.au/ListArchive/ticker-dev/archive/2002/04/msg00002.html thanks ... d From Matthew.Phillips at dsto.defence.gov.au Thu Oct 10 18:16:08 2002 From: Matthew.Phillips at dsto.defence.gov.au (Phillips, Matthew) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec Message-ID: <108E7D907871D6118B5000306E0189F8A6712D@ednex504.dsto.defence.gov.au> The spec says MIME-Attachment must be multipart. Is there any reason to mandate this? I'd like to attach simple URL's using Content-Type = "text/uri-list" and the URL(s) as the content. In fact I just noticed the example in the appendix does exactly that. Cheers, Matthew. > -----Original Message----- > From: David Arnold [mailto:arnold@dstc.monash.edu.au] > Sent: Thursday, 10 October 2002 4:42 PM > To: ticker-dev@dstc.edu.au > Subject: [ticker-dev] new revision of ticker v3 spec > > > i've put a revised specification of the Tickertape v3 protocol on > DSTC's FTP site for your comments > > ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-01.txt > > for reference, the previous draft remains at > > ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-00.txt > > changes in this revision: > > 1. "Replaces" is now a renamed "REPLACEMENT" with identical semantics. > > 2. attachments now use the "MIME-Attachment" attribute, rather than > "Attachment", and are a string, not an opaque. > > this has been quite controversial, and i'm not sure that this is > the best compromise. i'd encourage people to speak up if their > needs are not met ... > > three outstanding issues remain from the first draft (replaces has > been resolved). these are: security, the semantics of the > Distribution attribute, and the lack of explanatory and motivational > text. comments and contributions to any of those would be great :-) > > see > > > http://elvin.dstc.edu.au/ListArchive/ticker-dev/archive/2002/0 4/msg00002.html thanks ... d From blaize at dstc.edu.au Thu Oct 10 18:31:16 2002 From: blaize at dstc.edu.au (Blaize Rhodes) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: <200210100640.g9A6eok03766@xevious.dstc.monash.edu.au> Message-ID: <003e01c27037$a3f4b230$0100a8c0@snoopy> I know this has been said before, but... I think that the whole idea of a tickertape message format is contra the elvin philosophy (which I see as allowing increased scalability by decreasing coupling between applications). Message formats are like channels in the effect that they have on msg distribution (though perhaps at the higher level of granularity of tuple collections and not at the individual tuple level (where coupling occurs in channel based services)). I reckon a better approach would be i) to ascribe semantics to certain attributes (ontology-style) and then, ii) if you like, apply your MUST and MAY conditions to the ontology to define what's allowed in a standard "tickertape" msg. The difference is that by defining attribute semantics separately you allow reuse of those attributes in other msg formats and decrease coupling between applications based on the msg format adopted. The advantage this *may* bring is that at some stage previously unforseen applications can access the information in the attributes without having to know about the msg format(s) in which that attribute appears, i.e it decreases coupling between applications. Like I said, it has been said before, but I can't help feeling it's anti-elvin doing it this way . cheers blaize ----- Original Message ----- From: "David Arnold" To: Sent: Thursday, October 10, 2002 5:11 PM Subject: [ticker-dev] new revision of ticker v3 spec > i've put a revised specification of the Tickertape v3 protocol on > DSTC's FTP site for your comments > > ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-01.txt > > for reference, the previous draft remains at > > ftp://ftp.dstc.edu.au/DSTC/elvin/draft-arnold-ticker-chat-v3-00.txt > > changes in this revision: > > 1. "Replaces" is now a renamed "REPLACEMENT" with identical semantics. > > 2. attachments now use the "MIME-Attachment" attribute, rather than > "Attachment", and are a string, not an opaque. > > this has been quite controversial, and i'm not sure that this is > the best compromise. i'd encourage people to speak up if their > needs are not met ... > > three outstanding issues remain from the first draft (replaces has > been resolved). these are: security, the semantics of the > Distribution attribute, and the lack of explanatory and motivational > text. comments and contributions to any of those would be great :-) > > see > > http://elvin.dstc.edu.au/ListArchive/ticker-dev/archive/2002/04/msg000 02.html > > > thanks ... > > > > > d From ilister at dstc.edu.au Thu Oct 10 18:36:11 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: <003e01c27037$a3f4b230$0100a8c0@snoopy> Message-ID: On Thu, 10 Oct 2002, Blaize Rhodes wrote: >I know this has been said before, but... [snip] >Like I said, it has been said before, but I can't help feeling it's >anti-elvin doing it this way . I agree completely. Unfortunately the view is that `Tickertape is not Elvin'. I have also detected a significant anti-ontology feeling at various times, particularly when Julian suggested it earlier this year. Ian From arnold at dstc.monash.edu.au Thu Oct 10 20:10:01 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: <003e01c27037$a3f4b230$0100a8c0@snoopy> Message-ID: <200210100938.g9A9cnk04817@xevious.dstc.monash.edu.au> Approved: mdelvin -->"Blaize" == Blaize Rhodes writes: Blaize> I think that the whole idea of a tickertape message format Blaize> is contra the elvin philosophy (which I see as allowing Blaize> increased scalability by decreasing coupling between Blaize> applications). ok. Blaize> Message formats are like channels in the effect that they Blaize> have on msg distribution (though perhaps at the higher level Blaize> of granularity of tuple collections and not at the Blaize> individual tuple level (where coupling occurs in channel Blaize> based services)). i half agree with this. i think it's necessary to define the minimum set of elements that a Tickertape client application can reasonably expect to be present. but there's nothing that prevents an application using that minimal set of elements in conjunction with any others. so i accept the argument that the combination of Group, From, Message, Timeout and Message-Id forms a coupling between producers and consumers. but i think it's unfair to compare it to a pure channel-based system. Blaize> I reckon a better approach would be i) to ascribe semantics Blaize> to certain attributes (ontology-style) and then, ii) if you Blaize> like, apply your MUST and MAY conditions to the ontology to Blaize> define what's allowed in a standard "tickertape" msg. personally, i'd be happy to adopt that approach. i don't think it would necessarily change the current specification a great deal. i expect it will lead to different naming than we have now, and i worry about the impact that would have on client implementations, but perhaps if it can be resolved quickly? Blaize> The difference is that by defining attribute semantics Blaize> separately you allow reuse of those attributes in other msg Blaize> formats and decrease coupling between applications based on Blaize> the msg format adopted. in theory, yes. but in practice, this aim is unlikely to be perfectly achieved. Blaize> The advantage this *may* bring is that at some stage Blaize> previously unforseen applications can access the information Blaize> in the attributes without having to know about the msg Blaize> format(s) in which that attribute appears, i.e it decreases Blaize> coupling between applications. i think you can approach this ideal position, but i don't believe that it is reachable. i have seen enterprise-wide attempts to define an ontology of variable names, such that whenever you had to represent a particular entity, you could look up the ontology and use the standard name. this was a fine idea, in theory, and in practice it partially worked. but that was in a circumstance where it was actually possible to define a single, global, enforced ontological standard. i don't believe that is completely practical with Elvin. i'd suggest that the *combination* of names gives additional semantic context, and that while attempting to maintain a common ontology is a noble and worthwhile goal, applications will continue to rely on combinations of attributes to determine relevance of messages. this doesn't mean i'm not prepared to work on a common definition of the semantics of attribute names, just that i think we need to be realistic in anticipating its benefits. Blaize> Like I said, it has been said before, but I can't help Blaize> feeling it's anti-elvin doing it this way . so, is anyone prepared to write up a definition of the semantic concepts represented in a Tickertape message, and suggest names for them? d From arnold at dstc.monash.edu.au Thu Oct 10 20:23:28 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: Message-ID: <200210100952.g9A9qPk04904@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: >> Like I said, it has been said before, but I can't help feeling >> it's anti-elvin doing it this way . Ian> I agree completely. ok, so let's find a better way. Ian> Unfortunately the view is that `Tickertape is not Elvin'. i don't see how that is either unfortunate or relevant. but perhaps that's because i hold that view? please feel free to enlighten me. Ian> I have also detected a significant anti-ontology feeling at Ian> various times, particularly when Julian suggested it earlier Ian> this year. i personally suffer from scepticism, but i wouldn't characterise my position as "anti-ontology". i'm willing to work on such a beast, but contributions to the ticker spec so far have been conspicuous by their absence, and i'm not going to take on responsibility for generating an ontology as well. i'm happy to collate and publish submissions, if you like. d From ilister at dstc.edu.au Thu Oct 10 21:49:01 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: <200210100952.g9A9qPk04904@xevious.dstc.monash.edu.au> Message-ID: On Thu, 10 Oct 2002, David Arnold wrote: >ok, so let's find a better way. That would be good, but I am also OK to let Tickertape continue in the direction it is currently going, if that is what others want. > Ian> Unfortunately the view is that `Tickertape is not Elvin'. > >i don't see how that is either unfortunate or relevant. but perhaps >that's because i hold that view? please feel free to enlighten me. If the feeling is that the Tickertape way is divergent from the Elvin way rather than aligned with and the best example it can be of the Elvin way then Blaize's observation that giving standard meanings to attributes rather than whole notifications is more in the Elvin way is not relevant. So my point is relevant because it is tied to whether Blaize's point is relevant to Tickertape. I think that this is unfortunate because I think Tickertape has a lot to give Elvin and other Elvin applications (and that Tickertape and other Elvin applications can potentially gain by sharing rather than being independent protocols designed only for their own purposes and not for future extension or use in ways that are not currently done). > Ian> I have also detected a significant anti-ontology feeling at > Ian> various times, particularly when Julian suggested it earlier > Ian> this year. > >i personally suffer from scepticism, but i wouldn't characterise my >position as "anti-ontology". It's not just you I've got the feeling from, but I still think a 95% effort is still much better than ad-hoc use of attributes. >i'm willing to work on such a beast, but contributions to the ticker >spec so far have been conspicuous by their absence, and i'm not going >to take on responsibility for generating an ontology as well. > >i'm happy to collate and publish submissions, if you like. I am also happy to do it, and I probably should do it given that I'm the one keen on it and you're the sceptic :-) FWIW I think one of the main problems with an ontology for Elvin is going to be the problem of encoding, due in part to the simple data structures Elvin provides, but mostly because of a number of other reasons. At the simplest level an example is the problem of units - an attribute `Timeout' is not useful without knowing whether a numeric value is in seconds, minutes, or years. Naming attributes `Timeout-Minutes' is not so useful because it segregates information based on (easily convertible) units (and/or requires applications to represent the same information in many different ways). The classic temperature sensor example is another case - what units is `Temperature' in? Is it reasonable to define that applications should always use metric units of a particular scale? The renaming of Attachment to MIME-Attachment is really another example of the same problem - by specifying the encoding of the attribute's value in the attribute's name we make it clear what to expect in the attachment, but if there were other common ways of representing attachments then any applications that chose those methods would lose any potential for interoperating with Tickertape's attachments. In this case it seems that declaring that attachments should be in MIME whenever possible makes sense, but then perhaps the `Attachment' attribute should be defined to be MIME and the `MIME-' prefix in the attribute name (which is really only there to specify encoding) should be dropped. There are other encoding issues with simpler solutions, such as defining that lists of values should be `|' separated strings (as the presence protocol has defined for a few attributes it uses), but richer ability to represent more structured data in Elvin natively would help. Without it we rely on ad-hoc methods (such as the `|' list representation) and/or stuffing external structured formats such as MIME and XML into notifications, losing ability to (effectively) subscribe to their content. Any thoughts on any of this? Is this all just evidence that it won't work? Ian From arnold at dstc.monash.edu.au Thu Oct 10 23:37:28 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: Message-ID: <200210101306.g9AD6Ok06036@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: >> ok, so let's find a better way. Ian> That would be good, but I am also OK to let Tickertape continue Ian> in the direction it is currently going, if that is what others Ian> want. i'd really rather not hold up v3 much longer. if a quick resolution is possible, and there is a general acceptance of changes amongst the client authors, then i'm happy to change. otherwise, v4 is always possible. Ian> If the feeling is that the Tickertape way is divergent from the Ian> Elvin way rather than aligned with and the best example it can Ian> be of the Elvin way then Blaize's observation that giving Ian> standard meanings to attributes rather than whole notifications Ian> is more in the Elvin way is not relevant. if there is benefit to Tickertape to be had, then i'd be surprised if suggested changes were rejected outright. i don't see that it's possible to build a community of compatible applications without specifying a collection of attributes with common purpose. so while the approach to naming and definition of attributes might be different, i'm not sure that the resulting specification would change dramatically. Ian> So my point is relevant because it is tied to whether Blaize's Ian> point is relevant to Tickertape. the fact that Tickertape is not Elvin doesn't mean that specifying Tickertape notifications as a collection of independently-specified Elvin attributes is not relevant. Ian> I think that this is unfortunate because I think Tickertape has Ian> a lot to give Elvin and other Elvin applications (and that Ian> Tickertape and other Elvin applications can potentially gain by Ian> sharing rather than being independent protocols designed only Ian> for their own purposes and not for future extension or use in Ian> ways that are not currently done). what do you think Tickertape can give Elvin? all design should attempt to anticipate future extension and alternative uses. i would argue that the draft v3 specification is better than v2 or v1.x in that regard. but improvements are always welcome. Ian> I am also happy to do it, and I probably should do it given Ian> that I'm the one keen on it and you're the sceptic :-) good. Ian> At the simplest level an example is the problem of units - an Ian> attribute `Timeout' is not useful without knowing whether a Ian> numeric value is in seconds, minutes, or years. yep. Ian> Naming attributes `Timeout-Minutes' is not so useful because it Ian> segregates information based on (easily convertible) units Ian> (and/or requires applications to represent the same information Ian> in many different ways). can you suggest an alternative? i think it is perfectly acceptable to include the unit of measurement (if appropriate) in the semantics of an attribute. i'm less enthusiastic about including the units in the name -- you cannot put full semantic information into the name, so you might as well put the units into the same "offline" description as the remainder of the context? Ian> The classic temperature sensor example is another case - what Ian> units is `Temperature' in? Is it reasonable to define that Ian> applications should always use metric units of a particular Ian> scale? both of these cases reflect similar issues in API design. pick the units that are most broadly applicable, and accept that sooner or later, someone will need to more precision or greater range than you've anticipated. calling the anticipated relevant lifetime of a text message "Timeout" is probably the first problem to be addressed. given the general acceptance of minutes as the appropriate unit at the ticker-2k workshop, it would seem that the intended semantics have a natural range (as minutes). on the other hand, "Timeout" implies quite broad semantics to me, and my immediate inclination would be to use milliseconds as the unit. to me, this indicates strongly that there is a mismatch between the name and the semantics in the Tickertape context. "Temperature" is easier for me -- it has a simpler, more generic semantics. it should always be a floating point value in degrees kelvin. Ian> The renaming of Attachment to MIME-Attachment is really another Ian> example of the same problem - by specifying the encoding of the Ian> attribute's value in the attribute's name we make it clear what Ian> to expect in the attachment, but if there were other common Ian> ways of representing attachments then any applications that Ian> chose those methods would lose any potential for interoperating Ian> with Tickertape's attachments. cue correlation? Ian> In this case it seems that declaring that attachments should be Ian> in MIME whenever possible makes sense, but then perhaps the Ian> `Attachment' attribute should be defined to be MIME and the Ian> `MIME-' prefix in the attribute name (which is really only Ian> there to specify encoding) should be dropped. that was my initial logic. but given the general enthusiasm for using structured notifications to hold attachments, i think anticipating that alternative makes some sense, and thus distinguishing now is helpful. Ian> There are other encoding issues with simpler solutions, such as Ian> defining that lists of values should be `|' separated strings Ian> (as the presence protocol has defined for a few attributes it Ian> uses), but richer ability to represent more structured data in Ian> Elvin natively would help. perhaps. more complex, structured respresentations of data might also increase the chance that different applications represent the same information in incompatible ways. not that a natively structured representation is less transparent than an encoding convention for a simpler data type, but more that if it is possible to represent complex data in a single message, programmers will no longer be "encouraged" to find simpler representations. anyway, this is probably getting a little off-topic. Ian> Without it we rely on ad-hoc methods (such as the `|' list Ian> representation) and/or stuffing external structured formats Ian> such as MIME and XML into notifications, losing ability to Ian> (effectively) subscribe to their content. where does this line of argument end? consider: messages should be objects, because any subscription language that operates on decapsulated data is incapable of profiting from the embedded semantics provided by class methods. structured data is a step towards active networks -- not that i reject it necessarily on that basis, but i don't find the argument that structured data is necessary for effective subscriptions particularly compelling because taking it further (effectively to active networking) is clearly (imo) not elvin. Ian> Any thoughts on any of this? of course! Ian> Is this all just evidence that it won't work? not necessarily, just grounds for healthy scepticism :-) d From bill at dstc.edu.au Fri Oct 11 08:48:38 2002 From: bill at dstc.edu.au (Bill Segall) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: Message-ID: <200210102248.g9AMmcPf007761@piglet.dstc.edu.au> Ian> I have also detected a significant anti-ontology feeling at various Ian> times I'm one of the local anti-ontologists :-) I'm of the belief that language is a sufficiently complex system to hit the Goedel's proof point of complexity and that a complete ontology for a real language is a doomed exercise. I think it's doubly doomed by evolution and dynamicism of language but that's a different ideological set of objections about language and the need for it to fluid. Theoretical beliefs aside, it is remarkable what can be achieved heuristically and by a small set of definitions, examples include google/guidebeam (syntactic matching) and some work in the health sector of defining standards (semantic subsetting). By a strange coincidence, I was looking earlier in the week at the Worldwide Lexicon Project at: http://picto.weblogger.com/stories/storyReader$156 I think that's worth looking at although they're working at the how (protocols) end of the problem rather than the build (lexicon, dictionary, encyclopedia, translations), end. I think it's plausible that at some future point enough data may have been collected to allow something like an automated mapping from arbitrary data to a specific template (like the tickertape notions of users, group, and text) or perhaps just fields 1, 2 and 3) including translations etc. Being of the pragmatic type, I have always felt that the best approach to this was to provide a standardised set of fields as in a specification, and to provide an client interface that allowed arbitrary mapping of data to those fields. This mechanism allows a standardised defined approach, the ability for a user to add to their own personalised ontology, and leaves scopes for bots or agents that could automatically provide mappings (ala correlation). etiks is an example of a client that allows the user to map arbitrary messages onto the defined fields. There is still some thought going about this for xtickertape, I'm not really sure about the other clients. Bill. From arnold at dstc.monash.edu.au Fri Oct 11 10:39:08 2002 From: arnold at dstc.monash.edu.au (David Arnold) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: Message-ID: <200210110008.g9B080k09985@xevious.dstc.monash.edu.au> -->"Ian" == Ian Lister writes: >> i'm happy to collate and publish submissions, if you like. Ian> I am also happy to do it, and I probably should do it given Ian> that I'm the one keen on it and you're the sceptic :-) so, thinking last night, i started by trying to name the elements of a tickertape notification as standalone entities. this is reasonably involved, so let me start with just one: From this attribute is a tag by which the entity sending the message wishes to identify itself to receivers. in common usage that semantics is often split into two components: an informal entity identifier, and an informal location identifier. the intention behind the two parts is also two-fold: firstly to promote distinctiveness between the entity identifiers, and secondly to provide awareness of the current location of the sending entity. i'd note that these two intentions cannot, in general, co-exist (ie. "david@home" loses distinctiveness). in light of this combination of semantics, i see two options: - clarify the semantics to specify that this attribute is a presentation name for the sending entity, which could be named something like "Presentation-Name" or perhaps "Entity-Presentation-Name" - define a Tickertape-specific combined semantics, effectively "Entity-Presentation-Name-and-Locality-Presentation-Name" does this seem like a reasonable thought-process? i'm kinda interested in this particular attribute, because i think it is a good example of the issues involved in attempting to specify naming and semantics independent of their application. any comments on the semantics? d From ilister at dstc.edu.au Mon Oct 14 14:36:28 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: [ticker-dev] new revision of ticker v3 spec In-Reply-To: <200210101306.g9AD6Ok06036@xevious.dstc.monash.edu.au> Message-ID: On Thu, 10 Oct 2002, David Arnold wrote: >i don't see that it's possible to build a community of compatible >applications without specifying a collection of attributes with common >purpose. so while the approach to naming and definition of attributes >might be different, i'm not sure that the resulting specification >would change dramatically. I agree, but I see the difference being that we would design Tickertape to be a part of a potential community of compatible applications. Recently it has seemed that it is being developed more as a standalone application without consideration for interoperating with other applications, but that's possibly an inaccurate perception on my part. >what do you think Tickertape can give Elvin? The ability to support a variety of other applications interoperating with and getting value from existing Tickertape users, applications and traffic without Tickertape having to be explicitly designed to support these other applications and without these other applications having to be contorted to deal with `the Tickertape way'. Generally and perhaps more importantly, point (3) in my original mail is about Tickertape giving Elvin a good example of how to design an application for Elvin. > Ian> Naming attributes `Timeout-Minutes' is not so useful because it > Ian> segregates information based on (easily convertible) units > Ian> (and/or requires applications to represent the same information > Ian> in many different ways). > >can you suggest an alternative? I would go with `Timeout' being defined as being in some arbitrary unit (as below). >i think it is perfectly acceptable to include the unit of measurement >(if appropriate) in the semantics of an attribute. i'm less >enthusiastic about including the units in the name -- you cannot put >full semantic information into the name, so you might as well put the >units into the same "offline" description as the remainder of the >context? Yep, I agree, at least in cases where units are easily convertible in both directions without loss. In the more general encoding case this may not always be true. >calling the anticipated relevant lifetime of a text message "Timeout" >is probably the first problem to be addressed. > >given the general acceptance of minutes as the appropriate unit at the >ticker-2k workshop, it would seem that the intended semantics have a >natural range (as minutes). on the other hand, "Timeout" implies >quite broad semantics to me, and my immediate inclination would be to >use milliseconds as the unit. > >to me, this indicates strongly that there is a mismatch between the >name and the semantics in the Tickertape context. Yep. So, anybody up for defining `Timeout' to be in milliseconds? Or perhaps for compromise we could put it in seconds and allow applications wanting finer control to use floats? > Ian> In this case it seems that declaring that attachments should be > Ian> in MIME whenever possible makes sense, but then perhaps the > Ian> `Attachment' attribute should be defined to be MIME and the > Ian> `MIME-' prefix in the attribute name (which is really only > Ian> there to specify encoding) should be dropped. > >that was my initial logic. So...back to `Attachment' then? ;-) Seems reasonable given the way we're currently heading. >but given the general enthusiasm for using structured notifications to >hold attachments, i think anticipating that alternative makes some >sense, and thus distinguishing now is helpful. Hmm...perhaps... >more complex, structured respresentations of data might also increase >the chance that different applications represent the same information >in incompatible ways. > >not that a natively structured representation is less transparent than >an encoding convention for a simpler data type, but more that if it is >possible to represent complex data in a single message, programmers >will no longer be "encouraged" to find simpler representations. That is true - hence even greater need for predefined attribute structures ;-) >anyway, this is probably getting a little off-topic. Perhaps for this list, but I think it would (or should) be on-topic for elvin-dev. Perhaps we should move there? (If it's not on topic for elvin-dev or elvin-users then we need somewhere it is on-topic, because it is important :-) > Ian> Without it we rely on ad-hoc methods (such as the `|' list > Ian> representation) and/or stuffing external structured formats > Ian> such as MIME and XML into notifications, losing ability to > Ian> (effectively) subscribe to their content. > >where does this line of argument end? At some appropriate trade-off ;-) >consider: messages should be objects, because any subscription >language that operates on decapsulated data is incapable of profiting >from the embedded semantics provided by class methods. > >structured data is a step towards active networks -- not that i reject >it necessarily on that basis, but i don't find the argument that >structured data is necessary for effective subscriptions particularly >compelling because taking it further (effectively to active >networking) is clearly (imo) not elvin. I have always seen CBR as a big step towards active networks, and allowing CBR on more structured data doesn't seem like (relatively) much of a further step (just doing the same thing better). On Fri, 11 Oct 2002, David Arnold wrote: >so, thinking last night, i started by trying to name the elements of a >tickertape notification as standalone entities. > >this is reasonably involved, so let me start with just one: > >From [snip] In the area of user identifiers we currently have two distinct types: 1. A `screen name', used in Tickertape, the presence protocol and coffeebiff. I would describe this as something like `an informal short name (possibly a login name), which may optionally have appended an `@' symbol followed by a short informal organisational or physical location qualifier' (where `short' may be defined more exactly in terms of words, characters, and/or just by example). 2. A `unique name', used in the presence protocol, which is modeled after an email address and would have a description similar to the above but mandating a unique domain part (and a unique name within the domain). The fact that the presence protocol already distinguishes the two (and that the other protocols' usages fit neatly and fairly consistently into type 1) seems to lend weight to this classification. >i'm kinda interested in this particular attribute, because i think it >is a good example of the issues involved in attempting to specify >naming and semantics independent of their application. Yep. Ian From ilister at dstc.edu.au Wed Oct 16 16:28:00 2002 From: ilister at dstc.edu.au (Ian Lister) Date: Tue Oct 14 08:01:43 2003 Subject: standard attributes In-Reply-To: Message-ID: I defined a handful of standard attributes yesterday and put them up at http://staff.dstc.com/ilister/attributes.html. The only thing that's really causing me angst at the moment is the lack of ability to nest tables of attributes again... consider for example etrap, which can send information about both the network host the notification is about and the monitoring host that is sending the notification. In this case it would be nice to have a notification like: Trap: { Hostname: printer1.example.com } Agent: { Hostname: snmp.example.com Process-Id: 9432 } ... That way you can subscribe to all notifications about a specific host (or hosts in your domain) with "*.Hostname == 'host.example.com'" or similar. Note that there's nothing to stop you sending a notification equivalent to the above as: Trap.Hostname: printer1.example.com Agent.Hostname: snmp.example.com Agent.Process-Id: 9432 ..but you can't subscribe to a specific host (without enumerating every possible prefix). Similarly, presence requests list the requestor as `Requestor' to make the role clear even though the same information could go just as well in a (less meaningful but more general) `User' field. I guess this is what more structured data representations like XML are good for, but it seems to me that it's still well within the scope of what Elvin should be... Ian