Multiple tuples in PIDF Why use multiple tuples

Multiple tuples in PIDF • Why use multiple tuples? – Because there are multiple sources of presence – Multiple • Could – Multiple multiple information for a presentity publishers signify persons, devices, etc contact addresses in tuples signify ways to contact the presentity • exact • Ao. R (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

Tuples w/ contact addresses: the different models • Registration model – Tuples are husks for contact addresses, address you subscribe to is Ao. R • 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 Ao. R Markup model – Use single Ao. R 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

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?

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?

Face-to-face presence • Note? – If not, why not?