Subject: [Simple] Tuple design team discussion summary

From: Robert Sparks <[email-masked]>
Date: 26 Jun 2003 14:32:56 -0500

Folks -

The tuple design team has been working since the interim meeting
to build a clearer picture of how we can make the best use of tuples.

This team was able to reach consensus on the following points:

- A tuple with contact advertises a handle that can be used for    
  communication with the presentity. This is the foundation of 
  what a tuple "means".

- Tuples may expose supplemental status information that
  a watcher can use to distinguish between them.

- Presence agents can generate documents with many different
  policies for constructing tuples and we don't want to prevent that.

      Some example policies discussed include:
      o always building a document with a single tuple 
        representing a unified view of the presentity determined
        by the presence agent.
      o building documents where each tuple represents a unified
        view of communicating with the presentity using a particular
        type of media
      o building documents where each available communication endpoint
        is advertised as a separate tuple.

- We do not want to grant preferential status to any particular policy
  for constructing tuples.

      This point was intensely debated. The central point was 
      whether or not generic clients would be able to sensibly
      render (or make automated decisions using) documents 
      constructed with different policies. We achieved rough
      consensus that this was possible.

At the interim, we agreed that PUBLISH should identify the tuple
it is operating on using the id parameter. That approach is
consistent with the above conclusions, and Aki is proceeding with
the PUBLISH draft using it. (This has some ramifications which will be
discussed in a separate message.)

This is good progress - enough, I believe, that we can move forward
with it and finish the fundamental versions of many of our deliverables.

There are still questions around the use of tuples to be discussed.
The one this design team was circling around whether a PA needs to
expose the policy it used to create tuples to the watcher and whether
a watcher needs to be able to request a certain policy. This discussion
will move back to the SIMPLE list.

There are other positive by-products of this teams efforts, including
a model that Henning has started developing for describing operations
over a set of tuples that will be helpful as we address composition.

The tuple design team consisted of:

Adam Roach
Aki Niemi
Aziz Mohammed
Ben Campbell
Brian Rosen
Henning Schulzrinne
Jon Peterson
Jonathan Rosenberg
Keith Drage
Paul Kyzivat
Robert Sparks
Thanos Diacakis

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple