PIDF/Tuple discussion. Henning talking on phone, with  slides.

Some question about status of RPIDS and relationship with  PIDF as well 
as future direction. Mostly a dialog between  Jon P and Henning. 
Uncertainty regarding whether there will  be other customers of PIDF 
beyond SIMPLE. Decided this  isn't something we need to decide now, but 
we should not  abandon PIDF.

Henning asserted we lack a model for how a system involving  presence 
should work. His slides included his vision of how  this works. It was 
generally agreed that this is a  reasonable general model, but that 
there are many  differences in understanding hidden behind this picture. 
  Jon didn't agree that the caller would be expected to use  preferences 
in any algorithmic way to map the choices.

Jonathan believes there is a contract that if the caller  uses the 
contact in a tuple he can be expected to be routed  to something that 
has the characteristics of the tuple. He  doesn't want the caller to be 
responsible for qualifying  the contact to achieve this end. Brian 
agreed - said wasn't  tied to callerprefs as the solution to this, but 
felt it  was the natural solution. Jonathan said that there are many 
ways to achieve this - using GRUUs, callerpref parameters  on the 
contact address, etc.

Brian gave an example: he wants to have a single tuple and  address 
offering the following characteristics: high and  narrow bandwidth 
audio, and fixed and mobile phones. But  not all combinations are 
available - high bandwidth mobile  is not a valid combination.

There was a discussion of lifetime of the contacts in  presence. There 
was concern that these should not be  considered to be long lived. 
Agreement that there should be  more explicit specification of this. 
Henning said he would  add this to RPIDS.

I stated that there is an analogy between presence and 
registration/proxying: it moves into the hands of the  caller the 
decision that the proxy otherwise makes in  choosing among registered 
contacts.

Adam probed at definition of expiry: he goes to lunch and  publishes the 
url of his cell phone with an 'until'  parameter when he expects to 
return from lunch. But he  wants this to remain valid if he is late, 
until he updates  it.

Henning proposed contraint on tuples - the contract  mentioned above. 
Note that this doesn't require that every  tuple have a unique contact.

Brian said that there are two kinds of attributes of a  tuple - some 
describe current status, others describe  options that are available to 
the caller, possibly not in  all possible combinations. Jon P didn't 
like this  distinction.

There was extended discussion on this - hard to summarize.

There was a discussion of the viability of callerprefs as a  way of 
expressing capabilities, and of presence client  users being able to 
deal with this information. Some had  discomfort at problems with 
callerprefs. But Henning  pointed out that the capabilities side of 
callerprefs is  pretty stable. Jon wants to restrict the current work to 
  what is necessary to completing a presence system  sufficient for 
building a commercial IM system, and leave  any other considerations to 
later.

Henning proposed that removing <capabilities> from RPIDS is  easy, and 
can be itself postponed. Instead he suggested  setting a deadline. If 
the capabilities side of callerprefs  is approved by the deadline then 
the reference to it stays  in RPIDS. Otherwise it is removed.

Jon says he wants to separate the capabilities stuff into a  separate 
documents, so they can not be fate shared. Robert  agreed with this. 
That seems to imply that it *will* be  done.

Action items:

- add words about contact lifetime
- add description of contract
- separate callerprefs part into separate doc
- split different features into separate xml namespaces

Discussion about labeling tuples. Agreed that the PIDF id  semantics 
should be expanded within RPIDS to be assigned by  the source of the 
tuple (typically the publisher) and be  valid over a longer timespan 
than a subscription. Requires  that the set of publishers must produce 
ids that are  mutually unique.

Brief discussion of atomicity of tuples. There was general  agreement 
with this. Jonathan was concerned with a case  where a cell phone 
publishes its status in one tuple and  something else publishes the 
geoloc of the phone as a  separate tuple. Jonathan wants to end up with 
a composed  tuple representing both these things. But he doesn't like 
the idea of needing three tuples to achieve this. The  evolved into a 
discussion of relationships between tuples.  Something needs to 
understand a relationship and publishes  the results under its own 
ownership.

	Paul Kyzivat