hack of VOEvent to include W3C signature

[Rob Seaman]

Steve wonders:

> Doing a quick paraphrase of the relevant RFC, the typical MTA relay
> information in SMTP is to include a bunch of lines of this form:
>
> 	Received: from some.smtp.relay.host (related DNS information)
> 		(various parenthetical information)
> 		by another.smtp.relay.host with some_protocol
> 		for some.user at some.machine; date_timestamp
>
> If this sort of relay information is desirable in a VOEvent packet,
> should there be a formal specification for that in the VOEvent schema?

If we were to include such, yes - and in fact, SMTP is a perfectly  
fine delivery method for an event.

But publish/subscribe is not quite the same paradigm as postal  
delivery to a specific address.  Or rather, an event is more like  
receiving a magazine than a first class (perhaps certified) letter.   
Our routing is of interest to the publishers, but not the subscribers.

An interesting paradigm shift to consider, though.  Just ordered a  
gawdawful expensive replacement lamp for our rear projection DLP TV.   
This is a specific, high value item whose rapid and reliable delivery  
I care about, so part of the purchase transaction was selecting a  
specific class of delivery, UPS 2nd Day Air.  They claim it's in  
stock, so it should ship tomorrow and I'll be given a routing number  
to check on all those SMTP-style relay messages.

Still don't see a VOEvent connection, especially since our network  
should be quite simply connected, perhaps indefinitely - maybe one or  
two hops in the middle.  LSST publishes events in one hemisphere,  
they get forwarded to the other hemisphere, and perhaps once more  
through a trans-Atlantic cable.  SMTP typically involves several more  
hops.

> Signature elements could be part of that.

Indeed.  One of the analogies of public key cryptography is to an  
envelope protecting the contents of the message.

> Again, this is more complexity, albeit optional complexity.

Optional it would certainly have to remain.

Rob