Minutes, SIMPLE, IETF54
SIMPLE Working Group, IETF 54 0900-1130 17Jul02
Chairs: Jon Peterson (jon.peterson@neustar.biz)
Robert Sparks (rsparks@dynamicsoft.com)
Full Notes (taken by Dean Willis)
Agenda presented, accepted
MESSAGE Update, Ben Campbell
MESSAGE method in IETF last call, waiting IESG feedback. There have
been several small changes. This draft has added an option for large
messages if congestion-safe transport is 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 that 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 systems use multiple data elements to drive the
applications. 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 discussion on tradeoff
of authorization, inheritance, and cacheing issues followed. Open
issues include 1) Do enough of the data manipulation type things 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
include CPL problem in scope, Proposal, No. 2) Is "slot" idea right
way to go? 3) Do we need to standardize PType tokens? 4) 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. Comment: 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).