Message-id management revisited

[Mike Fitzpatrick]

> No Mike, this was not your original suggestion:

You're right, what you quote is your list of options.  I was referring to
the
first comment on 4/28 (and following discussions) when this hub-msg-id
thing first appeared in the doc:

   *** Introduction of sender-msg-id/hub-msg-id is a new, overly complex,
>        detail.  If the receiver gives back the same msg-id why does the hub
>        need to add anything to it?  If the the msg-id contains some bit of
>        identifying sender info it doesn't need any sort of mapping at all,
>        if the msg-id is a random string then this mapping stack is an
>        implementation detail.
>            I STRONGLY suggest we lay down a msg-id format or Hub respons-
>        ibilities in handling truly opaque id strings,
>



> I want to avoid going backwards on this.  We already have Thomas,
Alasdair,
> Luigi and me in favour of 9.  Mike, if you can find support among other
> participants for a different one of the existing proposals
> (or some new one) on this topic, we can continue the debate, otherwise I
am
> going to go ahead with 9.

Like I said, my vote was probably moot.

-Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ivoa.cacr.caltech.edu/pipermail/apps-samp/attachments/20080611/733ff48e/attachment-0001.html>