VTP 1.2 Draft

[John Swinbank]

Dear all,

Many thanks for the feedback both on- and off-list so far.

Roy pointed out that I should probably have more explicitly drawn your attention to the changes I've made in this new draft. These are:

Version 1.2 adds two new sections to the document: Section 2.1, outling design goals of the protocol, and Section 7, detailing requirements for message de-duplication to avoid network loops. In addition, it adds an explicit time  requirement to connection maintenance packets (Section 4) and clarifies the semantics of nak transport messages (Section 5.3). Finally, it emphasizes that the authentication schemes outline in Section 8.2 are not tied to a particular cryptographic system.

Cheers,

John

On 7 Aug 2012, at 18:43, John Swinbank <swinbank at transientskp.org> wrote:

> Dear all,
> 
> Over the last several months, the LOFAR Transients Key Project (of which I am a member) has been experimenting with sending and receiving events using the transport protocol defined by Alasdair Allan & Bob Denny <http://www.ivoa.net/Documents/Notes/VOEventTransport/>. While this isn't (and doesn't claim to be) the be-all and end-all of VOEvent transport protocols, it is simple, easy to implement and has been working well for us.
> 
> In the light of the experience we've gained over this period, I, in discussion with Alasdair and Bob, have made some changes to their document to resolve ambiguities and clarify some sections. The basic protocol remains the same, and the intention is that any client which complies with their published version 1.1 will also comply with revised version.
> 
> A draft of my revisions is available from <http://www.transientskp.org/static/vtp-1.2-draft.pdf>. I would very much value your feedback – are these changes an improvement? Are there other aspects of the protocol which should be clarified or expanded while we have this opportunity? What have I not thought of? I should emphasise that, although I've discussed my changes with Alasdair and Bob, they haven't signed off on every word of this draft yet, so errors and omissions are entirely my own.
> 
> As a reminder, a variety of published software implements the protocol:
> 
> - Dakota Tools <http://voevent.dc3.com/> are a suite of C# tools providing a message broker and the ability to send, receive and validate messages. Dakota has been developed by Bob Denny.
> 
> - Comet <http://comet.transientskp.org/> provides a Python implementation of much the same, developed by yours truly on behalf of the LOFAR Transients Key Project.
> 
> - NASA GCN <http://gcn.gsfc.nasa.gov/> publishes VOEvents using this protocol. They provide a client which is able to receive events from their servers or from others, developed by Scott Barthelmy and Teresa Sheets.
> 
> (There may also be other implementations of which I am not aware.)
> 
> LOFAR Is now starting to move towards a production environment (see <http://www.astron.nl/radio-observatory/astronomers/asking-time/asking-time-0> for details on the currently-open call for proposals). That means we are now focusing on deploying a functional system soon: although I personally am always interested in blue-skies discussion about what might be interesting someday, we plan to move forwards with this protocol, at least for our initial deployment. Therefore, I'm primarily hoping for comments that pertain to the specifics of this particular protocol, rather than a more general discussion.
> 
> Cheers,
> 
> John