SIMPLE Issues

1
SIMPLE Issues

• Jonathan Rosenberg
• dynamicsoft

2
Presence Changes

• Alignment with bis and sip-events
• Removal of ¾ examples, removal of PIDF
• Additional words on security, usage of SMIME and
  sips
• Recommend PUA implement this package, so network
  can subscribe to user
• Formal IANA registration
• Split references
• RFC 2119 section

3
Winfo Format changes

• First-subscribed refers to first subscribe for
  this subscription instance, not first ever (per
  SLC)
• Removed notify-address
• Added expiration parameter
• Removed most-recently-subscribed
• Alignment with bis, sip-events
• Generalization of wording to watching any
  package, not just presence

4
Winfo Format Pending Changes

• Need to add id and version parameters to watcher
  element
• Supports sending of watcherinfos with list of
  only those watchers whose state has changed
• Watcherinfo subscriber needs to compute complete
  list by taking most recent version of each
  watcher data
• Watcher info package assumes these exist
• Should have submitted together ?

5
Watcherinfo Package Changes

• Clarified wording
• Alignment with sip-events
• Discussion of forking next slide
• Described how to construct complete watcher list
  from partial updates
• More information on selecting the giveup timer

6
Forking

• Watcherinfo from the presentity needs to get to
  all servers handling subscriptions from the
  presentity
• Two ways
• Forks at the proxy to ALL PS and installs many
  subscriptions
• Server fronting PS knows subscription state, acts
  as PA for winfo (state agent)
• Subscriptions from watcher on same dialog

PS
Winfo subscribe
PS
PS
Each presence server handles 1/3 of the
subscriptions
7
Watcherinfo Pending Changes

• Screwed up IANA considerations need to register
  template package
• State agent text not right we are actually
  using them

8
Open Issue

• Duration parameter in watcherinfo
• Conveys duration in previous state
• Sensible when NOTIFY is sent on state transition,
  meaningless on fetch
• Solutions
• (1) Define a duration in current state
• Meaningless for event triggered NOTIFY
• (2) Define duration in previous and current
• (3) Provide no durations

9
Proposed work plan

• Nits and sanity review of the docs
• Update with pending changes and nits comments,
  Friday April 5
• Submit to IESG

10
IMTP Revisited

• Refresh IMTP is a subset of SIP, removing
  features that get in the way
• Forking
• Redirection
• UDP
• Observation new bis loose routing may make those
  issues moot

• Can mandate that loose routes for MESSAGE only
  involve TCP hops
• In bis, ONLY proxies that own domain in R-URI can
  run location service
• If that is the FQDN or IP of the end host, no
  element in the network will run LS
• No forking, no redirection

11
Proposal

• IM sessions be handled by series of SIP MESSAGE
  requests
• The message sessions specification documents the
  additional requirements for that usage

12
Page Mode, Session Mode, and Groups

• Groups exist in both page and session modes
• We need to define a clear set of requirements and
  scenarios for both modalities, for both one-one
  and group
• We need to specify transition scenarios

13
One-One Page v. Session

• Few messages
• Small messages

• Large messages
• Overload sip network?
• HOL blocking the tcp connection
• Many messages

14
Group Page v. Session

• When there is a common view of membership
• When multiple media are involved
• When participants wish to join without being
  invited
• When you wish to invite a participant to join
• When you wish to have moderation of the
  conference
• When you want to know identities of the
  participants

• One to many broadcasts
• Sidebars in a conference
• When you dont want/have a central server
• But central server could be endpoint

15
Open Issues

• Threading and Order
• Threading is the subject
• Order is the sequence
• Needed for both page and session models
• Group addressing
• Page mode how to identify the participants in
  the group that should receive the request
• How a recipient knows the other participants that
  got the request (requirement?)

• How to reply to the group
• Do we specify maximum message size for page mode?
• NB bis will automatically use TCP for big stuff

16
Big Open Issue

• Big one how much effort do we want to expend on
  adding functionality for group mode IM?

17
Simple Components

• SIP and SIMPLE are general purpose tools for
  building applications
• SIMPLE alone is not sufficient for a complete
  buddylist consumer app
• Not news to any of us
• BUT we need to have all of the tools to build
  such an app

18
Features of a Buddy List App

• Group chat
• Add, remove, floor control, participant ID
• Finding buddies
• Profiles, searching
• IM message storage
• Retrieval, manipulation
• IM delivery confirmation
• SMS interworking
• Presence publication

• IM/Presence authorization
• Add, remove, list members on allow/deny lists
• Content vault
• Transfer files

19
The Challenge

• Does IETF provide the tools sufficient to build a
  complete interoperable service?
• Answer NO
• BUT We have frameworks for much of it!

20
What are we missing

• Data manipulation
• Add/remove buddies
• Add/remove members from allow/deny list
• Web works, not always
• Notification Services
• Is-typing indicator
• Conference participation
• Message delivery confirmation
• Message Store
• Notification of new messages, fetch, delete,
  file, etc.
• Message history
• Nice to be common for email, voice, IM

• Group Conferencing
• Add/remove members
• Floor control
• Content sharing
• Message vault
• URI indirection
• Threading
• Publication
• Tie it all together

21
Proposal for SIMPLE

• Adopt buddylist package as a work item
• Adopt development of a solution for is-typing
• Adopt development of a set of IM statuses for PIDF

• Finish message sessions
• Threading solved as part of it
• Adopt a work item to develop the needed data
  manipulations for buddylist, allow/deny
• Presence document publication
• Architecture doc (informational) tying it together

22
Proposed New For SIPPING (fyi)

• Adopt call package as a work item
• Adopt conference package as a work item
• Message confirmation package specification be
  defined

• Content indirection in SIP
• Formerly part of sip-events

23
Homeless

• Message store manipulation/history
• VPIM?
• Content vault manipulation
• Webdav?
• Floor control, conference policy
• A bof?
• Profiles, user and group discovery
• Whois??

24
Proposal

• Request group agree to work on these
• Would like to have an informal gathering later to
  discuss further