1 / 9

Rich presence: RPID, CIPID, future-presence draft-ietf-simple-rpid draft-ietf-simple-cipid draft-ietf-simple-future

Rich presence: RPID, CIPID, future-presence draft-ietf-simple-rpid draft-ietf-simple-cipid draft-ietf-simple-future. Henning Schulzrinne Columbia University with V. Gurbani, P. Kyzivat, J. Rosenberg. Issues. Changes since last IETF Open issues RPID: none CIPID: <card>

charlee
Download Presentation

Rich presence: RPID, CIPID, future-presence draft-ietf-simple-rpid draft-ietf-simple-cipid draft-ietf-simple-future

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Rich presence: RPID, CIPID, future-presencedraft-ietf-simple-rpiddraft-ietf-simple-cipiddraft-ietf-simple-future Henning Schulzrinne Columbia University with V. Gurbani, P. Kyzivat, J. Rosenberg SIMPLE - IETF 59 (Seoul)

  2. Issues • Changes since last IETF • Open issues • RPID: none • CIPID: <card> • future-status: model, past only? SIMPLE - IETF 59 (Seoul)

  3. Changes since last IETF • Split into three documents: • RPID: <activity>, <class>, <contact-type>, <idle>, <placetype>, <privacy>, <relationship>, <sphere> • CIPID: <card>, <homepage>, <icon>, <map>* • future-status • Changed <idle>* • <idle since=“2004-02-28T18:02:15Z”/> • Finalized ‘since’ and ‘until’ mechanism for RPID • describes validity of elements • must bracket tuple timestamp (present) • Updated schemas* *since cut-off SIMPLE - IETF 59 (Seoul)

  4. CIPID: <card> vs. <homepage> ? • <card> contains URL to vCard or LDIF • vCard contains homepage URL (url:) • duplicates <homepage> element • but not all <card> elements may allow this • awkward if only the homepage is to be conveyed • need data: URL with lots of syntactical noise • recommendation: leave both since possible duplication is harmless SIMPLE - IETF 59 (Seoul)

  5. CIPID: by value or by reference ? • Currently, only reference to vCard or LDIF record • Can include by value using data: URL or MIME URLs (mid:) • MIME URLs are awkward since they require that CPIM message is multipart-MIME capable – specified? • But reference more bandwidth-friendly if repeated in each NOTIFY • CPIM model seems to favor full state • can use partial updates to avoid problem SIMPLE - IETF 59 (Seoul)

  6. CIPID: by value or by reference ? • Solution 0: • make do with data: and mid: • Solution 1: <card type=“text/url”>http://foo.com”</card> • Solution 2: <cardurl>http://foo.com</cardurl> <card type=“MIME type”>vcard or LDIF data</card> SIMPLE - IETF 59 (Seoul)

  7. * used to be called timed-status future-status* • RPID can indicate time ranges, but must be valid at <timestamp> (~ present) • otherwise, plain PIDF implementations would misinterpret historical or future status as present status • Useful to have a separate mechanism to indicate predicted presence value • e.g., from calendar information or sensor • allows watcher to plan communication • allows coordination: “when is everyone likely to be available in the next few hours?” SIMPLE - IETF 59 (Seoul)

  8. future-status • Should we add <past-status> or allow <future-status> to handle this? Yes • Useful if only old information is available, but it’s better than no information • “was on AA167 until three hours ago” <future-status from=“2004-08-15T10:20:00” until=“2004-08-16T08:19:00”> <basic>closed</basic> {all other PIDF and RPID elements} </future-status> ? SIMPLE - IETF 59 (Seoul)

  9. Conclusion • Believed to be ready for WG last call after one more round • but may need to define semantic policy rules for RPID, CIPID and future-status • Current solutions for open issues are workable and we could add suggestions later • <past-status> • <card> value SIMPLE - IETF 59 (Seoul)

More Related