[ticker-dev] Ticker group "invitation" attachments

[Phillips, Matthew]

So I'm guessing (a) no one cares (fair enough ;) or (b) no one hates this idea badly enough to flame me. Either way, does anyone object to me assuming this is a reasonable proposition and writing a short document to "standardise" it on tickertape.org?

Matthew.

> -----Original Message-----
> From: ticker-dev-bounces at tickertape.org 
> [mailto:ticker-dev-bounces at tickertape.org] On Behalf Of 
> Phillips, Matthew
> Sent: Wednesday, 1 September 2004 11:46 AM
> To: 'ticker-dev at tickertape.org'
> Subject: RE: [ticker-dev] Ticker group "invitation" attachments 
> 
> After a brief hiatus, here's a new (improved! now with the 
> crunchy goodness of angle brackets!) ticker group attachment 
> format, by example:
> 
> ----
> 
> <group version="1.0" name="Chat" type="chat" />
> 
> <group version="1.0" name="CNN" type="news" />
> 
> <group version="1.0" name="Private Chat" type="chat"
>        defaultSecure="true" allowInsecure="false">
>   <keys>
>     <key version="1.0" name="Private Chat" 
> access="shared">1234567890abcdef</key>
>   </keys>
> </group>
> 
> <group version="1.0" name="foobar" type="custom">
>   contains (Message, "foobar") ||
>   equals (From, "frodo")
> </group>
> 
> ----
> 
> Note that I've just mapped the existing key name/value format 
> into XML attribute form.
> 
> Matthew.
> 
> > -----Original Message-----
> > From: ticker-dev-bounces at tickertape.org 
> > [mailto:ticker-dev-bounces at tickertape.org] On Behalf Of Phillips, 
> > Matthew
> > Sent: Thursday, 26 August 2004 2:54 PM
> > To: 'ticker-dev at tickertape.org'
> > Subject: RE: [ticker-dev] Ticker group "invitation" attachments
> > 
> > [David]
> > > -->"Matthew" == Phillips, Matthew
> > > <Matthew.Phillips at dsto.defence.gov.au> writes:
> > > 
> > >   Matthew> I was kind of just seeing this as a natural 
> complement to
> > >   Matthew> the key file format.
> > > 
> > > That's a reasonable model, I reckon.  But being lazy, I
> > just figured
> > > that using ep/ec syntax, and notification-compatible naming
> > made more
> > > things easier in future ... :-)
> > 
> > I agree, I like the simple format. But it's easy to hit the limits.
> > 
> > >   Matthew> But being able to optionally embed the key(s) with the
> > >   Matthew> invitation would make more sense - I didn't go there
> > >   Matthew> because the name/value format isn't composable. Dare I
> > >   Matthew> mention XML? ;)
> > > 
> > > Maybe MIME's multipart/related (RFC-2112) and CID URLs
> > > (RFC-2111) would be a better approach?
> > 
> > That also sounds like work, and it could be fun seeing if the MIME 
> > parser I've snaffled will deal with that ;)
> > 
> > > Well, you could compose them using XML, but I think keys 
> and groups 
> > > are better as independent entities?
> > 
> > The nice thing about XML is that it allows keys and groups to be 
> > separate or embedded eg:
> > 
> > <group version="1.0">
> >   <name>Private Chat</name>
> >   <type>chat</type>
> >   <defaultSecure>true</defaultSecure>
> >   <allowInsecure>false</allowInsecure>
> >   <keys>
> >     <key version="1.0">
> >       <name>Private Chat</key>
> >       <access>shared</access>
> >       <data>xxxxxxxxxxxxxxxx</data>
> >     </key>
> >   </keys>
> > </group>
> > 
> > i.e. the embedded key(s) just follow the format of a standalone key.
> > 
> > A bit offtopic, but does anyone have any feeling as to whether the 
> > above is more "correct" XML or the following:
> > 
> > <group version="1.0" name="Private Chat" type="chat">
> >   <keys>
> >     <key version="1.0" name="Private Chat"
> >          defaultSecure="true" allowInsecure="false"
> >          access="shared" data="xxxxxxxxxxxxx" />
> >   </keys>
> > </group>
> > 
> > I like the terseness of the above, but it somehow doesn't 
> feel right 
> > ;)
> > 
> > >   >> In the case where the receiver doesn't already have
> > the key, and
> > >   >> the use of an existing, secure Elvin channel to deliver it
> > >   >> doesn't exist, then you're left with other means: a
> > PKI, HTTP(S),
> > >   >> email, sneakernet, SMS, voice, etc.
> > >   >>
> > >   >> This is where Jinx tried to help -- if you can send 
> a message,
> > >   >> with deliver_insecure set false, and including the 
> known public
> > >   >> keys of all intended receivers, you can send the key 
> inline ...
> > > 
> > >   Matthew> You can do that with Sticker too btw.
> > > 
> > > So could you safely include the keys in a ticker
> > attachment, since you
> > > can control who sees it using their advertised key?
> > 
> > Yep.
> > 
> > >   >>  I guess it wasn't a major release, but it brought it
> > up to spec
> > >   >> with latest v3 rules, added the ability to reload your
> > keys file
> > >   >> without restarting and added the use of SIGHUP to
> > cause a reload
> > >   >> of all config files.  Fairly major improvements albeit not
> > >   >> especially visible ones.
> > > 
> > >   Matthew> V3 support is good. Now all we need is Aquatik to do v3
> > >   Matthew> (fully ;) and we can drop the v1/v3 hybrid
> > ticker messages.
> > > 
> > > And all the various bots, applets, etc, that continue to use
> > > v1 format messages.
> > > 
> > > But you're right -- it's a fine thing :-)
> > 
> > Do any bots out there *listen* for v1 only? I imaging we'll have to 
> > listen for v1 forever, but at some point we can stop 
> emitting it from 
> > user agents.
> > 
> > Matt.
> > _______________________________________________
> > ticker-dev mailing list
> > ticker-dev at tickertape.org
> > http://www.tickertape.org/mailman/listinfo/ticker-dev
> > 
> _______________________________________________
> ticker-dev mailing list
> ticker-dev at tickertape.org
> http://www.tickertape.org/mailman/listinfo/ticker-dev
>