Message-id management revisited

[Douglas Tody]

On Fri, 6 Jun 2008, Mark Taylor wrote:

> I am arguing for something very similar to this: the only difference
> is that instead of the msg-id form being fixed as <client-id>-<msg-tag>,
> the hub can choose how it builds its msg-id from the <client-id> and
> <msg-tag>.  The only additional complication that this causes is that *if* the
> sender needs to know the msg-id that the hub has generated
> (and it is rare that it will - it's not required simply for matching
> messages with responses) then it will have to get it from the hub, e.g. using
> a translation method or waiting for a round trip at send time.  As in the
> above scheme, the hub does not need to maintain any per-message state (except
> for synchronous messages, which is not what we're talking about here).

A simple solution might be to allow the messaging system to add
additional properties to message headers, which the client is required
to preserve if it responds to a message.  These would be private
to the messaging implementation; the spec merely says how they are
stored in the message.  I suspect this would be an important capability
to provide.  It would seem to cover the use-case you mention.

The client's message-id however, is merely a tag known to the client
which it may use to keep track of messages, for example to associate
an asynchronous response with a request.  There is probably no reason
to require a particular format for this: <client-id>-<msg-tag> is a
reasonable suggestion, but in general the format used might depend
upon the client messaging API.  The messaging system need not use this
property at all, it could instead be part of the application messaging
protocol.  (This is all sounding rather similar to email headers which
deal with both transport as well as arbitrary application-defined
semantics).

It is not clear that any state is required in the messaging system,
except to maintain information on open client connections, per-client
subscriptions, accounting statistics, and the like (ignoring state
associated with services which are bundled into the "hub").

	- Doug