ISSUE: Message-id management

[Mike Fitzpatrick]

Hi Mark,

the scheme as it is stands in the draft can use exactly the trick that you
> describe to avoid storing any per-message state internally.
>

>
> The most obvious way to do it is for the hub to set its hub-msg-id along
> the following lines:
>
>   <hub-msg-id> = <sender-id>-<sender-msg-id>
>
> then, as you describe, when the response comes back to the hub bearing the
> <hub-msg-id>, the hub can unpack this to work out where and how it's
> supposed to forward that response on to the original sender.


    If this is the intent of having a separate hub-msg-id then  it should be
spelled out
more clearly in the text, but it still looks like just a wrapper around the
idea of how
to format the sender-msg-id to carry the same information.


> I understood that your earlier proposal was to say the sender MUST
> supply a msg-id with a format like that above, and the hub MUST leave
> it the same when it forwards it to the recipient.


    It has to be a MUST, anything less and the hub still has to handle the
id mapping so any benefit is lost because one developer decided to ignore
a SHOULD.




> The benefit of allowing the sender-msg-id and hub-msg-id to be different
> (though they don't have to be if the hub wants to arrange things
> otherwise) is so that the sender and the hub can both decide how they
> want to format their part of the ID.  As well as not wanting to dictate
> implementation details where it's not necessary, there may
> be practical benefits to this - for instance a particular hub
> implementation might want to add a checksum for added security.
> If it is obliged by the standard to use a msg-id of a particular form,
> and generated by the sender, that would be outlawed.
>

    You should have stopped at the 'not wanting to dicate' argument.  Unless
the receiving app knows it is getting a checksum in the id and does
something
with it a checksum value is no more secure than adding "-foo" since all
we need is the reply to give us back the same msg-id.  If you want checksum
security it should be in the original sender, but then we're back to
dictating
implementation details.

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