RPIDS Henning Schulzrinne Columbia University 1 July 2003 SIMPLE - - PowerPoint PPT Presentation

rpids
SMART_READER_LITE
LIVE PREVIEW

RPIDS Henning Schulzrinne Columbia University 1 July 2003 SIMPLE - - PowerPoint PPT Presentation

RPIDS Henning Schulzrinne Columbia University 1 July 2003 SIMPLE - IETF 57 (Vienna) Issues Changes since last IETF Organization Predictive items Informational items Completeness Capabilities proposal 2 July 2003


slide-1
SLIDE 1

July 2003 SIMPLE - IETF 57 (Vienna) 1

RPIDS

Henning Schulzrinne Columbia University

slide-2
SLIDE 2

July 2003 SIMPLE - IETF 57 (Vienna) 2

Issues

  • Changes since last IETF
  • Organization
  • Predictive items
  • Informational items
  • Completeness
  • Capabilities proposal
slide-3
SLIDE 3

July 2003 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
slide-4
SLIDE 4

July 2003 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

slide-5
SLIDE 5

July 2003 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

slide-6
SLIDE 6

July 2003 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>
slide-7
SLIDE 7

July 2003 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

slide-8
SLIDE 8

July 2003 SIMPLE - IETF 57 (Vienna) 8

Predictive presence

slide-9
SLIDE 9

July 2003 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

slide-10
SLIDE 10

July 2003 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

slide-11
SLIDE 11

July 2003 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

slide-12
SLIDE 12

July 2003 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>