Signing events

[Roy Williams]

Bob

Well I think the question is really about the level. There is the socket 
level, where you send some bytes that say how many bytes you are 
sending, based on the 1993 GCN protocol. It seems little has changed 
since the good old days of anonymous FTP.

Other protocols, such as HTTP, HTTPS, and XMPP are more sophisticated. 
You don't send bytes, you send messages and headers and identities. 
Browsers can do all the tricks. The same libraries that are needed for 
vTCP (twistd, mono) can also handle these more sophisticated methods. 
But, as you point out, vTCP is the only thing that has been written up 
for the IVOA, and there are funding cuts, so we must make it do what we 
need it to do, because that is "what everyone else is doing".

What would really improve vTCP, in my opinion, is the ability to send an 
event *and* a set of key-value pairs at the same time (sideband). A 
<VOEvent> and a <Transport> together in the same message would do it. 
That way many things would become possible that cannot be done if each 
message is nothing but a VOEvent. You can ask in the sideband for 
something to be done with the event, for example: publish, validate, 
replicate repositories, run intelligent annotation, recommend 
observation parameters to the follow-up facility, it becomes much richer.

Is this possible?
Roy


On 3/5/12 4:16 PM, Bob Denny wrote:
> You said:
>> In the longer term, I can imagine a whole panoply of different uses for signed events, and that's the problem: if we deploy Bob's system now, does that damage our future prospects? If we follow a more complex scheme, is it going to hit a complexity wall – or, at least, take so long to mature that it can't meet our needs this year?
> Of course, as Norm points out (and as have others before him over 6
> years) there are all of the old objections like "what if we rip apart
> the message and normalize it, and store it in a mapped database, or run
> it through a DOM, blah blah, and then later reconstruct it in a
> normalized form, and..." Feel free to chase your collective tails for
> another 6 years.
>
> Meanwhile, if you are OK with the VOEvent message not being altered
> (_which after all seems to be the whole idea to me_), and if you are OK
> with using PROVEN/VETTED security tools (GPG/PGP) which are widely
> understood/accepted and which do not require expensive or untrusted (and
> difficult to manage) X.509 certs, and and and... No libraries. Just a
> command line executable. I'm waiting for the "scalability card" to be
> pulled next :-)) The DigiSig option of the Transport 1.1 spec provides
> publisher authentication and message integrity. The logic needed is
> trivial as shown by the simple perl scripts that are published in the
> Transport 1.1 IVOA Note. If you haven't looked at it, it might be nice
> to do so.
>
> And are we ever going to stop calling Transport "vTCP" or "vanilla" or
> ??? which is not indicative of the particular spec ("Handshake" or "IVOA
> Note", significant differences!) and elicits the type of question to
> which Alasdair just responded, and which comes from those who just don't
> want to learn the details about it?
>
>    -- Bob

-- 
---
Caltech LIGO
roy at caltech.edu
626 395 3670