Apps Messaging -- A New Approach

[Mike Fitzpatrick]

	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