SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

RPIDS

bbeth avatar
bbeth
12 diapositives · 141 Views · Jan 06, 2020

This document discusses the changes made to the SIMPLE protocol since the last IETF meeting. It covers issues, organization, predictive items, informational items, completeness, and capabilities proposal.

#rpids #rpids ppt #powerpoint #presentation
RPIDS - slide 1
01 / 12RPIDS
1 / 17

Télécharger la présentation

RPIDS
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. RPIDS Henning Schulzrinne Columbia University SIMPLE - IETF 57 (Vienna)

  2. Issues • Changes since last IETF • Organization • Predictive items • Informational items • Completeness • Capabilities proposal SIMPLE - IETF 57 (Vienna)

  3. Changes since last IETF • Removed group notion • Removed capabilities again (to avoid blocking on caller preferences) • Renamed some elements • Added <card>, <info>, <class>, <icon> • Merged idle notion into one element SIMPLE - IETF 57 (Vienna)

  4. Additions: class parameter • Allows grouping of elements by same name, assigned by PUA, PA or composer • No specific meaning attached to values • No uniqueness requirements • Similar to HTML parameter used for cascading style sheets (CSS) • Uses: • Rendering (e.g., for CSS or XSLT) • Filtering by watcher • Composition rules • Restrictions by presentity SIMPLE - IETF 57 (Vienna)

  5. Changes: <idle> • Used for hinting at likelihood of finding presentity at device • For some devices (e.g., cell phones), works best for short durations • Change: empty element indicates some presentity-defined threshold of idle time SIMPLE - IETF 57 (Vienna)

  6. Logical groupings of elements • Basic status indications: <activity>, <idle>, <until> • Environment indications: <placetype>, <privacy> • Rendering hints: <icon> (tuple), class • Relationship indication: <relationship> • Presentity description: <icon>, <card> • Timed status: <timed-status> SIMPLE - IETF 57 (Vienna)

  7. Information about tuples/presentities: info, card, icon • <info>: typically, home page, but could be ldap: or (future) CRISP reference • By external reference (could be cid) • Allows more useful rendering of tuples • E.g., some existing systems (GAIM) allow to assign icons to users, not just status • Cannot be readily replicated in SIP Info headers if at tuple level (multiple!) • Also, with third-party publication, not clear if Call-Info refers to SIP entity or PIDF entity SIMPLE - IETF 57 (Vienna)

  8. Predictive presence SIMPLE - IETF 57 (Vienna)

  9. Document structure options • Leave as is • Split into • <activity>, <idle>, <until>, <placetype>, <privacy>, <class> • predictive presence: <timed-status> • presentity description: <icon>, <card>, <info> • capabilities SIMPLE - IETF 57 (Vienna)

  10. Open issue: DND • In previous version, used priority indication: “only for urgent calls” • Gone with removal of capabilities, but very common in commercial IM systems • Proposal: either revive/revise callee capabilities quickly or import directly SIMPLE - IETF 57 (Vienna)

  11. Capabilities • Old mechanism was syntactically clumsy and unnecessarily different from other descriptions  makes filtering and restrictions more difficult than necessary • Treating labels as values violates XML design principles of tagged data, would be the same as doing<x tag=“body”><x tag=“h1”>Heading</x> • New tags need to be registered with IANA anyway  might as well automatically ‘translate’ into XML element at the same time SIMPLE - IETF 57 (Vienna)

  12. Capabilities proposal • <c:audio>true</c:audio><c:video>true</c:video><c:mobility>fixed</c:mobility><c:methods>INVITE,MESSAGE</c:methods> SIMPLE - IETF 57 (Vienna)