Current Meeting Report
Slides
2.1.8 SIP for Instant Messaging and Presence Leveraging Extensions (simple)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
Chair(s):
Robert Sparks <rsparks@dynamicsoft.com>
J. Peterson <jon.peterson@neustar.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
P. Faltstrom <paf@cisco.com>
Applications Area Advisor:
P. Faltstrom <paf@cisco.com>
Mailing Lists:
General Discussion: simple@mailman.dynamicsoft.com
To Subscribe: http://mailman.dynamicsoft.com/mailman/listinfo/simple
Archive: Archive: http://mailman.dynamicsoft.com/pipermail/simple
Description of Working Group:
This working group focuses on the application of the Session
Initiation Protocol (SIP, RFC 2543) to the suite of services
collectively known as instant messaging and presence (IMP). The IETF
has committed to producing an interoperable standard for these
services compatible with the requirements detailed in RFC 2779 and
in the Common Presence and Instant Messaging (CPIM) specification,
developed within the IMPP working group. As the
most common services for which SIP is used share quite a bit in common
with IMP, the adaptation of SIP to IMP seems a natural choice given
the widespread support for (and relative maturity of) the SIP standard.
The primary work of this group will be to generate:
1. A proposed standard SIP extension documenting the transport of
Instant Messages in SIP, compliant to the requirements for IM
outlined in RFC 2779 and in CPIM and in BCP 41 (so that the
transport implications of the extension with respect to
network congestion are considered in the design). The extension
will document the mappings from its operations to CPIM.
2. One or more proposed standard SIP extensions documenting a
subscription and notification service within SIP, used to support
presence, compliant to the requirements for presence outlined in
RFC 2779 and CPIM. The extension will document
the mappings from its operations to CPIM.
The working group will work within the framework for presence and IM
described in RFC 2778. The extensions it defines must also be
compliant with the SIP processes for extensions. The group cannot
modify baseline SIP behavior or define a new version of SIP for IM and
presence. If the group determines that new security capabilities are
needed from SIP, the group will seek to define such extensions within
the SIP working group, and then use them here.
The working group will operate in close cooperation with the IMPP
working group, which will be completing CPIM in parallel. The working
group will also cooperate with any other groups defined to standardize
other presence and IM systems, to ensure maximum sharing of
information and avoid reinvention of the wheel. The working group will
cooperate with the SIP working group, soliciting reviews to ensure its
extensions meet SIPs requirements. The working group will also
collaborate with the SIP WG to ensure consistent operation of the
SUBSCRIBE and NOTIFY method across the other applications being
defined for its use.
Goals and Milestones:
| MAR 01 | | Submission of Extensions for Instant Messaging to IESG |
| MAY 01 | | Submission of Extensions for Presence to IESG |
Internet-Drafts:
- draft-ietf-simple-presence-07.txt
- draft-ietf-simple-winfo-format-02.txt
- draft-ietf-simple-winfo-package-02.txt
- draft-ietf-simple-cpim-mapping-01.txt
- draft-ietf-simple-presencelist-package-00.txt
No Request For Comments
Current Meeting Report
Minutes, SIMPLE, IETF 54Minutes, 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).
Slides
Agenda
MESSAGE Draft Status
SIMPLE Drafts
The PUBLISH Method
3GPP Presence Requirements
- Krisztian Kiss
- Gabor Bajko
IMSX Protocol Evaluation for Session Based IM