1. Multiple tuples in PIDF
Why use multiple tuples?
Because there are multiple sources of presence information for a presentity
Multiple publishers
Could signify persons, devices, etc
Multiple contact addresses in tuples signify multiple ways to contact the presentity
exact
AoR (single SIP tuple) model – an alternative
Only a single contact address for SIP is exposed through presence
Granularity of presence information blankets all user capabilities/devices
This is totally clear, but perhaps not so useful

2. Tuples w/ contact addresses: the different models
Registration model
Tuples are husks for contact addresses, address you subscribe to is AoR
Contact addresses are different from one another
Getting at contact addresses through the registration process rather than through presence
However, some devices might not be able to publish presence
Correspondence with registration may not be exact
Single AoR Markup model
Use single AoR with markup (caller prefs) to reach individual devices
Capabilities in tuples differentiate alternatives
Caller prefs vs. finding “the best way to communicate”
Requires extensions
Both should work at least as sensibly as the single tuple model

3. Tuples w/o contact addresses
When is it used? Multiple choices:
URI you use to subscribe to presence is the same you would use to communicate
Non-representable communication addr (since PIDF requires URI as addr)
CLOSED tuple
Geopriv
What do all of these have in common, if anything?

4. Interoperability concerns
Fallback to baseline PIDF
But what does baseline PIDF mean?
Is it possible to create tuples that would not be compatible with the baseline?
Receiving tuples with extensions at incompatible devices
What if I get two tuples for the same URI – one open, one closed?

5. Face-to-face presence
Note?
If not, why not?