Rough Notes, SIMPLE, IETF54

Notes SIMPLE Working Group, IETF 54 0900-1130 17Jul02

Agenda presented, accepted

MESSAGE Update, Ben Campbell

  MESSAGE method in UETF last call, waiting IESG feedback. There have
  been several small changes. This draft has added an option for large
  messages if congestion-safe transport os used. Also clarified
  Expires header, although new discussion of this topic has occurred
  on list in the last 24 hours. Use of 0-value Expires as "immediate"
  request label is an open question vs "Priority". Audience poll
  favored current usage with 0-value. There has been discussion of a
  stronger requirement for REGISTER with method-message. Current
  discussion is to leave it as currently documented. Motion made from
  floor to leave well enough alone -- barring major issues, just go
  with the current form.

CPIM Mapping, Ben Campbell

  Recent draft has minor changes to sync with 3261, but has CPIM
  dependencies. IMPP chair Mark Day reports that CPIM has experienced
  a resurgence of interest and may be the last deliverable from IMPP,
  with a due date on the order of "a couple of months".

SIMPLE Data Manipluation Requirements, Jonathan Rosenberg

  Presence List Changes:

  Terminology change from "buddy list" to "presence list" in latest
  draft. More data than PIDF needed due to requirement for partial
  update, including full/partial update flags to allow differential
  updates. Lists may include lists, so the list server subscribes to
  list package for each entry rather than the basic presence package,
  thereby providing nesting. 

  Open Issue #1: Should PL be a Template package? Discussion presented
  in slides. Open question -- is a new body type required? Current
  draft proposes a multipart body with a madatory base class and an
  optional seperate "collection" body with references to other
  elements. This preserves the original bodies in an unmodified
  fashion and allows package-indpendent collection servers. Example
  bodies presented in slides. Comment from floor: this has some
  similarity to SynchML and may justify examination thereof. Comment
  from floor: This multi-level approach is interesting, but the given
  approach has a lot of overhead. Also the proposal doesn't seem to
  have any way to distinguish multiple elements. 2nd comment
  adddressed, spec requires that templateable packages specify a URI
  to reference elements. Application/versioninfo should be an XML
  document with full referencing. Comment from Patrik: Mixing MIME
  dividers and XML dividers can be problematic, especially if
  signatures are used. Response: Reason author likes multipart/mixed
  rather than pidf is that this appproach preserves signatures and
  seems to work. 

  Open Issue #2: Too Many Choices

  Current draft allows PIDF, PLIDF, Multipart Mixed, all of which have
  assorted issues discussed in slides. The Collection Template
  approach discussed above seems to allow mixing of these types while
  clearing all of the noted issues. 

  Open Issue #3: State of Suscriptions

  The Presence List Server is a "fan-out" server. There's currently no
  way to know the state of the fanned-out subscriptions on a
  transitive basis. Proposal is to aggregate this information in
  listinfo format as proposed in collection template class, then
  support partial updates. Discussion: What would the event header
  look like? Proposed alternative: multipart/mixed with message/sip
  inside. This would reduce maintenance of collection
  formats. Response is tha t this would keep all of the overhead of
  SIP routing information -- cseqs, etc. and would create a great deal
  of overhead problematic for wireless applications. 

  Open Issue #4: Sharing Of Versions

  Issues discussed in slides, all cleared by proposed collection model.

  Open Issue #5: Which Package does PLS use?

  Several options proposed: 1) presence.collection, fallback to
  presence, 2) add labels to lists so they can be parsed as lists 3)
  user has to KNOW that a subscribed list is a list, not an
  individual, 4) Server OPTION The URI to discover that it is a list,
  then uses appropriate package, which works as long as role of URI is
  fixed. 5) disallow recursion. Comments requested: Question: How are
  1, 3 ,and 4 not complementary? Ans: Original proposal was "All but
  2". This results in notifications that exceed the scope of the
  subscription, which could be confusing to sort out. Question: How do
  you identify these? The event header was "buddy list", what now?
  Ans: It was always a request URI, the only thing that changes is the
  event name. Question: Could the AOR be a bddy list? Ans: Yes, but
  not in an overloaded condition where the URI presents both an
  indivdual and a list. This would seem to be a reasonable
  interpretation of URI usage. Question: What about multipart
  recursion? Extended discussion followed . . . discussion deferred to
  offline. Question: If something has presence but not presence
  collection, would it be reasonable to serve up presence instead of a
  prsence collection? Ans: yes. This will be clarified in
  draft. Audience polled: Is going in the direction of a template
  class generally reasonable? Answer favorable, none opposed.


Data Requirements, Jonathan Rosenberg
  
  Presence and IM ssytems use multiple data elements to drive the
  application. We need to manipulate these data items, interact with,
  change, etc. them. This is disjoint from the subscription and
  notification mechanism, and includes read and write mechanisms with
  caching (offline access, and modification) and security requirements
  (listed in draft). Question: Does this create additional
  requirements around concurrent offline changes and reconciliation?
  Ans: Not a requirements issue but an implementation issue. Comment:
  This topic could use its own working group, we should perhaps not
  solve it here. Ans: We're just talking about requirements and really
  expect to reuse an existing solution like SyncML. Comment: Should
  study data model in ACAP very carefully. Ans: Authors are already
  working with ACAP author to analyze. Extended discssion on tradeoff
  of authorization, inheritance, and cacheing issues followed. Open
  issues include 1) Do enough of the data manipulation type thihngs we
  do fit under this model to justify further work, 2) Should we
  generalize or do something specific for presence lists? 3) How do we
  align with SIP conf work? 4) Should we adopt as a WG item? Comment:
  This is a large problem space, and includes things like WebDAV,
  XPath, XML database, and probably becomes at least a New York sized
  rathole. It probably would be a bad idea to choose to do something
  limited to the presence list problem. Comment: There's a lot of
  overlap with W3C and other work, we should collaborate. Comment:
  This is similar to the UA configuration task, can we combine them?
  Comment: Is this really a semantic manipulation problem, or a remove
  text editing problem?  Comment: What is start with a pure XML
  framework, then we can use stuff like XPath and see if it
  works. Comments: We should at least work on this here, starting from
  specific topics in charter. Poll: Should this work be adopted as a
  wokring group item toward existing charter goal? Response favorable,
  none opposed.

The PUBLISH Method, Sean Olson
  
  The critical issues here depend on the composition model in the
  preceeding discussion. The basic model is discussed in the
  slides. The contentious component of the draft is the "slot" model
  of presence composition. Open issues include: 1) Should we
  includeCPL problem in scope, Proposal, No. 2) Is "slot" idea right
  way to go? 3) Do we need to standardize PType tokens? 40 Should
  PType require IANA registration? 5) Should PState be replaced with
  Expires header?  

  Comments: This seems to be the micro-version of WebDAV, but
  scope-limited for just the PL problem. This may argue that the very
  general "PUBLISH" name is too broad. Also, do we really want to
  differentiate between hard-state and soft-state data? Ans: Name can
  be changed. Authors have deliberately restricted to soft-state
  because this data has direct correlation or "binding" with SIP
  routing and cannot be well addressed by other mechanisms like
  WebDAV. Hard-state information does not seem to have this
  characteristic. This is particularly crucial for third-party
  manipulation of soft-state information given only a SIP URI as a key
  to that information. SIMPLE isn't deployable without this and it has
  to be fixed NOW. The requirement here is scoped explicitly by SIP
  Events. Comment: Can we identify a reasonable stopping point? The
  model of having to find a "stopping point" based on a SIP URI seems
  reasonably common. Proposal: Could we do PUBLISH via a reversed
  subscribe/notify model? Discussion of this approach not
  favorable. Question: How does one manage policy of slot composition?
  Ans: The composition policy of a compositor is locally determined.

3GPP Presence Requirements, Krizstian Kiss

  Slides summarize requirements. from draft. Discussion of requirememt
  "Keep all PUAs aware of each other's publishing": Comment that this
  seems to be contradictory, it would be better to make publishing
  transparent across devices. Ans: This is because we have "network
  attributes" that have to work this way. Further discussion
  deferred. Comment: there are requirements for filtering in a lot of
  our discussions, we should add to charter. Comment: partial
  notification is messy. We need to clarify this. For example, CPIM
  and partial notification are conflicting requirements. Comments on
  requirment for anonymous subscription: This means the subscriber is
  anoynmous, not that the subscription is invisible to the prsentity,
  right? Ans: yes. Comment: If geoloc is part of presence document,
  how does it get composited? Ans: simply -- just reference the geoloc
  document. There are lots of authorization issues around WHO can
  update and/or see geoloc. Discussion: Is it reasonable to accept
  requirement from 3GPP? Discussion: Rather than having "3GPP
  requriements" on our charter, shouldn't we simply integrate these
  requirements into our chartered requiremeents documents? This
  proposal seems to be generally favorable to the audience. 

3GPP Instant Messaging Requirements, Aki Niemi

  This document is intended as a "heads up" to IETF. The work is at a
  very early stage in 3GPP. Formal requirements are expected by IETF55.

IMSX Protocol Evaluation for Session-Based IM, Mary Barnes

  Analysis presented. Comment: Although it doesn't currently support
  threading, BEEP could so so easily. Aomment: Although there may be
  objections to implememnting yet another protocol in a node, SIP does
  shine at multiprotocol stories and really does work well with a mix
  of transports and codecs. Comment: The status of IMXP does not seem
  clear, as there have been apparent strategic shifts by the author
  (Jabber). Comment: Rohan said something about IMTP and strategic
  subsets and Fred Baker, but this reporter didn't parse it. Comment:
  messages are somewhat like media, and somewhat not like media, and
  we probably don't need a divergence between session and pager
  model. Comment: We seem to have only one proposal -- use SIP. The
  idea of defining IMTP as a seperate protocol subset seems
  pointless. Defining the session model as a stream of MESSAGES
  bounded by a dialog seems like the right thing to do. Comment: Using
  SIP without changing the name clearly violates the spirit and letter
  of our own SIP guidelines and has potential interop
  problems. Comment: If somebody is going to define a new proposal,
  they need to do it really soon. We really DO have only one draft
  under current consideration. Proposal: Let's just move forward with
  Jonathan's draft, in a non-exclusive sense. Discussion seems to
  favor this as the baseline default, and we can do additional stuff
  later if needed. We should immediately discuss on list and conclude
  whetehr we go forward immediately with SIP or a renamed SIP-subset
  (IMTP).