Re: Softlinks Across Outgoing Message Stores Necessary?

JCB> It might be important for IM2000 to offer the ability for 
JCB> senders to transfer their messages from one store to another,
JCB> notifying recipients accordingly, so they can update their
JCB> pointers.

Having RNASP clients being able to override prior notifications from other
RNASP clients raises all sorts of trustworthiness problems (which is why the
proposals make specific mention of how recipient notification agents should
determine whether two notifications are the same).

JCB> [...] it might be necessary for senders to be able to replace 
JCB> a message in a store with a link to its location in another
JCB> store.

It would be be relatively easy to come up with a protocol extension that
either extended the [ResponseRetrieve] response PDU in MSRAP or (probably
better) added a [ResponseRedirect] response PDU to a retrieval transaction
(and defined its semantics).

Concomitantly, MSOAP would also need a "redirect" transaction (probably
modelled somewhat on the "cancel" transaction).

Congratulations!  You've just invented the first extension to the protocols. 
(-:

JCB> (I think it'd be best if *readers*, rather than *stores*,
JCB> recursively followed such links.  Stores should serve 
JCB> messages and links stored only on them, not messages 
JCB> stored on other stores, even if their own messages link 
JCB> to them.)

Keeping the services simple is of course a good thing, and message stores
shouldn't talk to other message stores.  

The internal implementations of message stores can be as complex and as
distributed as one liked, however.  One can imagine, for example, a "load
balancing" message store software that allowed one to distribute an MSRAP
service across multiple machines, all served from a back-end database but with
their own local database caches.  In such a case a message store may well go
and fetch data from other places. 

But the IM2000 specifications should indeed be neutral with respect to such
things.  So the specifications shouldn't really be in the business of defining
such internal relationships between coöperating message stores.  As far as the
protocols are concerned, such a fetch would be entirely invisible and an
internal matter for the MSRAP server.