[ticker-dev] Ticker group "invitation" attachments

[Phillips, Matthew]

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
>