Apps Messaging -- A New Approach

From: Mike Fitzpatrick <fitz-at-tucana.tuc.noao.edu>
Date: Wed, 18 Apr 2007 23:42:58 -0700

        We seem to have reached a stalemate, or at least an unproductive state, in the discussions and so it may be time to try a different approach.

        My sense is that we would all be happy with an intial version of the spec that at least retains (and ideally improves) the current PLASTIC capability for current high-level tools to interoperate, but also recognizes that there are valid use cases that might not be handled in the first version and will be fixed later (perhaps involving significant changes). We've so far been working at this from the perspective of writing a spec from scratch with the idea of incorporating PLASTIC abilities into the new framework; what I'd like to suggest is that we explore the "cleaned-up Plastic" angle to see if we can make more headway by trying to turn PLASTIC into a v1.0 spec we can all live with. Note what I'm suggesting is still more than just a PLASTIC v1.1, but we use a different starting point in the discussion (and put the burden on the PLASTIC folks to propose a roadmap that everyone else can buy into instead of asking them to buy into a new idea).

        John had earlier posted (in the 'Apps Messaging - Twin track?' thread) his list of proposed changes but there were no replies to indicate how much opposition these would meet. These included some of the concepts we've already discussed such as a basic message content model through use of 'mtypes' rather than ivorns and asynchronous delivery -- do the PLASTIC developers see these things as fundamental obstacles to reaching some agreement?

        In the interest of neutrality, my own distaste for the 'VOOM' name (sorry Rob), and borrowing from the wisdom of others, let's call this the Simple Application Messaging Protocol (SAMP). It may in fact be a reworked PLASTIC but the 'Simple' part of the name may help keep us focused and remind us that a more complete protocol will follow. Keeping in mind our earlier limits that this be a single user/desktop system, separating message from transport etc, and recognizing that known limitations will need to be formally addressed as we move through the stds process anyway, I'd like to continue this thread by expanding and discussing John's list of changes from the PLASTIC perspective.

        To start, I'll ask whether we can reach some form of basic agreement about what's already been discussed, namely:

• Does the use of UCD-like 'mtype' offer enough of a basic content model that it can be expanded later? The mappings to plastic ivorns are trivial and I think can be used in the current plastic apps easily, their use in "advertising capability" and matching apps doesn't need to be part of the first spec.
• Have we specified all the needed message attributes? Too many? Not enough? Is this needed at all?
• I think it was Pat Dowler that came up with a Hub connection scheme that seemed agreeable, is that still true if we're modifying the PLASTIC hub?
• Can we agree on the workings of a broadcast vs directed message?

	This isn't quite the twin track approach John mentioned, but
perhaps we can get the Beijing with something real to discuss.	Those of

us interested in the generalities will be looking for the stubs in the spec we can use for later development, and I'm sure will be no less vocal in pointing out the important ones seen as missing.

        So, let the fun begin.....

-Mike Received on 2007-04-19Z08:43:32