Minutes: SIMPLE IETF 56 17Mar03 1530-1730
Reporters: Dean Willis, Pekka Pessi
Editor: Robert Sparks
Summary:
- Announced the impending SIMPLE Interop
- Called for volunteers to host a SIMPLE Interim before Vienna
- Consensus points
* Publish - Handling hard state will be left to local policy
- HTTP vs SIP discussion does not belong in requirements
document
- Meaning of "tuple" is unclear and needs attention
* RPIDS - draft (except ) accepted as starting point
for charter item
* isComposing - strong support to seek bringing this draft
into charter
* Filtering and partial notification requirements - strong
support to seek bringing these drafts into charter
==============================================================================
Notes reported by Dean Willis
Chaired by Robert Sparks, Jon Peterson
1530 Called to Order, Peterson
Topic: Agenda Bash -- no objections
Topic: Administrivia.
Revised charter pending. Reviewers needed for documents (Rohan volunteered).
Interop event needed. Volunteer for hosting by Jasomi at Banf or Calgary,
3rd or 4th week of April. Proposal for interim meeting before Vienna.
Topic: Message Sessions, Ben Campbell
History reviewed in slides. Message Session Relay Protocol (MSRP) work
attempted to resolve dependecy on co-media. Design work decided to abandon
co-media. Current draft is similar to cpm-msg-approach but addresses
multi-nat scenarios, common firewalls, multiple IM sessions on a transport
session. Some co-media issues resolved around bidirectional communications,
and relay support. Note that this protocol does not address relay discovery,
but relies on knowledge in endpoints. Note that in slides, all requests have
hop-by-hop responses except for SEND operation, which is end to end.
Open issue: ACK related bug in offer-answer, may address with UPDATE. Do we
need a refresh mechanism for BIND? There is also a race condition when
tearing down a session (between release and leave). Question re: refreshing
the BIND: Could we do one BIND instead of multiples using crypto cookies ?
(Send text).
Open Issues: Need to fully define msrp URI scheme. Do we needs msrps:?
Open Issues: Security. Digest auth on BIND needs to be specified. Question:
What do we get out of having digest auth on BIND? Do we need an msrps:
scheme? Note that there are three identities here -- the user identity, the
server identity, or an alias identity. This authentication is for protecting
the "bind" side of the relay. Currently, the "visit" side is not
authenticated. Note that the usage of TCP servers behind a firewall is no
more secure than running a UDP server behind a firewall. Further
conversation to list.
Topic: Publication of presence data: Jon Peterson, Sean Olson
Requirements document broken off from mechanism document: Jon Peterson
Open isue: Hard state requirements. Discussion defines "hard state" as the
default condition or absence of freshly published state. Question: Is there
a requirement for hard state? Poll: Should this be in scope of requirements?
Argument: This is a matter of local policy on the compositor function. So,
"hard state" as defined here is just policy. Audience (Henning): I agree
that this is a special case of policy. Is the manipulation of policy part of
the requirements? Question: Where does discussion of HTTP vs SIP live?
Requirements, or implementation?
Publication mechanism: Sean Olson
Changes since last draft simplified, now very much like "options" request.
Added new out-of-sync response code and versioning requirements, met by
time-stamp of CPIM-PIDF. PUBLISH is now non-dialog, soft-state, and
logically scoped to a tuple. S/MIME is used for privacy and integrity, and
compositor must respect end-to-end security requirements from the publisher.
Discussion: PUBLISH with an expiration has granularity of the contained
document, not individual tuples. This might preclude composite of end-to-end
protected tuples.
Issues: Need better definition of tuple. Discussion: This is one of the most
fundamental things to work on, but we argued against defining it in IMPP.
Much discussion on definitions illustrated we don't have one. Issue, do we
need Facet header for authorization of tuple watching. Question: Can we say
that RPIDS is a better PIDF that people will actually use? Unresolved.
Topic: RPIDS, Henning Schulzrinne
Motiviation and overview given on slides. In short, a presence information
format for publication and notification. Adds device capabilities.
Represents groups, with status within the group. Suggestion that group
representation be abstracted into a different document. There is also an
aspect of list composition functions that is needed. Issue: label tag, which
is similar to the pidf id tag but has defined semantics on setting by
presentity and applies to publication rather than notification side. In
short, there should be no two tuples in the same presence document that have
the same label. Issue: elements, no discussion. Issue: what is a tuple.
Three models presented: common AOR, generated by capability set, and
contacts representing devices (wityh privacy and duration issues). Proposed
that we document all three, but where? Comment: This does need to get
resolved -- can we get this nailed down by interim? Can we adopt this as a
WG effort? Poll: document seems widely-read. Given that, should this
document be a wg iterm reflected in charter? Strong consensus indicated.
Topic: IsComposing (istyping) state indication (vs idle): Henning
Schulzrinne
Slightly revised, open issues under discussion, poll to make WG status? This
will require deliverable add on charter. Poll to add iscomposing to SIMPLE
charter? Strong consensus shown. Comment from future AD: Would like to have
discussion of extensibility model. Comment (Bon Wyman): There have been
notifications of IPR on istyping. Can we work around this IPR? Comment from
AD: Part of the WG's evaluation is around IPR issues, so this discussion is
valid, and consideration should be given to the IETF's IPR declarations page
Topic: Data Manipulation, Jonathan Rosenberg
Point: This is general application data manipulation and is worthy of a
broader discussion. ACAP provides a model. Proposal includes algebraicly
scoped lists of lists-or-nodes. The ACAP data model seems to be a good fit,
bu the protocol itself has issues around persistent connections, lack of
intermediary support, underlying security primitives (SASL), and syntax
inconsistent with SIP. Discussion ranged around comparison of ACAP attribute
model and relationship to XML. Question raised as to "why look at ACAP --
it's old" Comment: Could we use WebDAV? Comment: The configuration work in
SIPPING could probably support this. Further discussion deferred to list.
Note that this basic piece of functionality is a critical show-stopper for
SIMPLE deployments.
Topic: SIP List Events, Adam Roach
Revised as a full event class rather than as a template. Open issue:
filters, several points need review. Author requests review of the XML usage
(Sean Olson volunteered). Proposal for downstream forking example received
no objections. Needs more eyeballs.
Topic: Partial Notification Filtering, Hisham Khartabil
Motivation and requirements presented. Proposed solution is XPath
expressions, leaving an open issue around triggering ("when", as opposed to
"what"). Poll: Is there a need for this sort of thing? Discussion:
Watcherinfo and others are using similar functions, so it is probably
useful. Discussion: Xpath may not have sufficient expressivity. Poll: Have
reqs drafts been read? Yes. Poll to bring reqs drafts onto charter, mostly
positive.
Topic: Partial Notifications Mikko Lonnfors
Defines requirements for partial notifications. Discussion: One requirement
is to "not change charging model" -- that's probably out of scope for this
WG. Poll: "go forward with this draft": moderately positive, no negatives.
===============================================================================
Notes reported by Pekka Pessi
Administrativia
---------------
* interop
* interim meeting before Vienna
- call for volunteers/sponsors
Message Sessions (Campbell)
---------------------------
* draft-campbell-simple-im-sessions-01
* MSRP
- attempts to solve problems related with COMEDIA
- lot like message sessions discussed in Atlanta
- differences:
- no comedia
- handle intermediaries more explicitly
JR: more than NATs, handling intermediaries within different admin
domains
- supports common fw policies, where parties behind
- problems with COMEDIA
- no good way to match incoming connection to particular session
- NAT breaks COMEDIA usage of source addr and port
JR: comedia uses port number as principal multiplexing identifier,
that cannot be used with intermediaries
- implicit support for two or more relays
- MSRP primitives:
- BIND: establish session
- relay discovery protocol is out of scope
- VISIT: associate connection with a session
- Host/Visitor:
- diagram explaining host/visitor relationship
- diagram explaining one relay case: host-relay-visitor case
- diagram explaining two relay case: host-relay-relay-host
- this is tricky
- relays can establish connections between each other based on DNS
information from message uris
- Open issues:
- ACK-related Bug in o/a handling:
- refresh mechanism for BIND
- race condition when tearing down a session
Aki Niemi: BIND only once, use a cookie to make difference between
sessions
Rohan Mahy: use soft state for BINDing
- msrp: URI scheme
- SDP encoding assumes that the host and visitor temp URIs have same domain
- Additional work needed for security
- digest authentication
- msprs needed for security?
Jon Peterson: what are security properties we need?
JR: relay wants to make sure that only a authenticated user
may set up binding on it?
RS: use TLS to prevent anonymous usage?
AN: what is the identity that is being authenticated
BC: authentication is only between host and relay
Cullen Jennings: do we need to authenticate visitor?
JR: provide same level of protection as in COMEDIA,
make msrp URIs unguessable to prevent anyone from being a visitor
CJ: make sure that no-one can use this to create a generic
socket server that can be exported outside firewall
- end-to-end security
- MIKEY, etc.
RS: object very very soon on the mailing list if this
draft is not on the right path
PUBLISH requirements
--------------------
- there is hard state and soft state for the presence
* Requirements for hard state (or default state)
* Use PUBLISH or something else to set the hard state
* Hard state in or out?
Aki Niemi: there should be such a concept; when you are out of
the coverage you should have somthing to deliver to subscribers
Sean Olson: should hard/default state be CLOSED?
RJ: the default state is a matter of policy, policy covers hard state
Adam Roach: installation of hard state is out-of-scope of PUBLISH
HS: this is a special case of policy, there should be mechanisms to upload
the default document
SO: it is requirement for presence/publish system, it can be done with
data manipulation, too
JP: should the default presence document contain a CLOSE tuple or may it
be empty without any tuples at all?
- HTTP v. SIP discussion is out of scope of the requirement doc
draft-olson-simple-publish-02
-----------------------------
- updates from -01:
- was too complex, removed extra headers
- added 494 Out of Sync
- because removed headers, added set of requirements for the
semantics of the PUBLISH body (that are fulfilled by CPIMP)
- versioning handled by the body ( for CPIMP)
- no dialog
- PUBLISH handles only soft state
- PUBLISH is scoped to a tuple
=> each tuple can be manipulated separately
- when end-to-end security (like S/MIME) is used, compositor
must respect that
HS: we must be very careful with tuple-ids
SO: publisher can handle each tuple separately
JR: this is extremely PIDF-specific
SO: this is only model that makes sense if you want to manipulate tuples
separately
- Issues:
- examples were missing Max-Forwards
- definition of tuple is unclear?
BC: important issue
JP: each tuple is identified by an unique contact address of my PC?
AN: (does a tuple contain a) contact address of you?
Dean Willis: tuples are attribute-value pairs for presentity?
- Do we need Facet header for authorization of tuple watching (ie. "Who
sees what?")
AN: this is definitely a policy issue
RPIDS
-----
* richer presence information than basic PIDF
- SIP-aware, translatable to CPIM easily
* merged with cp-based documents for describing presentity properties
* Draft overview
- Presence status
- Timed status: new thing
- e.g., person was in a meeting an hour ago
- Device capabilities
- Allow presentity to represent groups
* Problems:
- groups can contain groups
- at odds with list presence (but more efficient)
- ok, ditch groups for now
BC: agree
RS: was going to ask pulling groups to a document of its own
RJ: current list does not handle the combined status very well, the
status of the group is useful and should be kept
* Problems:
- PIDF has id tuple tag
- allows handling of diffent tuples
- who owns each id? how to handle it?
RJ: "id" is for receivers, something else is needed for composition
- use "label" tag on backend side
- also use something like css (which has id and class)
- each element has two kind of identifiers
-> enables policy filtering
* Open Issues:
- extending
- ortogonality: how to combile activities
- What is a tuple?
- AOR, custom address for each capability set, device address?
HS: solicits comments
JR: this is most important issue
Brian Rosen: have a bar bof
=> Hum accepting this draft as working group item
is-composing
============
* Bob Wyman: there is some IPR issues
* Patrik Fältström: WG should take into consideration potential IPR when
processing a document, nothing more, nothing less
Data Manipulation
=================
* manipulate buddy lists
* manipulate authorization policy
* examples
ACAP (RFC2244)
* generic mechanism for application-independent access to per-user
application configuration data from multiple clients
- Presence list with ACAP
- Authorization policy with ACAP: requires defining processing logic of
authorization entries, no need for scripts
- Data model of ACAP is fine, protocol is bad
- sasl (ACAP security model) is not compatible with S/MIME etc
- no intermediaries allowed
HS: has concerns with data model
C. Huitema: why unearth this protocol? why not LDAP or SNMP?
JR: take things that work, replace things that won't for use
RM: use something that has a URI
AN: document has two sides, nice datamodel and so-and-so protocol
JP: split document? take it to list
Presence Lists (Adam Roach)
===========================
* take 3: an extension to sip-events
- list contents as a multipart
- meta info in xml mime body part
* open issue: filters? do they apply to top-level list, the nodes, or both?
RM: do we need to take this to sipping?
JR: we are chartered to do this
Presence Filters (Hisham Khartabil)
===================================
* eliminate unnecessary and unwanted notifications and contents
* solution based on XML style sheets (XPath)
JR: triggering stuff is needed (winfo)
there is many different stuff going on here
filter can be generic, triggering probably package-specific
HS: while xpath can do simple arithmetic, semantics of triggering and
filtering may be different, xpath may not be enough, CPL-like approach
might be better?
JP: motivation/requirements draft can be taken in charter
Dean Willis: solutions documents might be better in SIP WG
Partial Notifications (Mikko Lönnfors)
======================================
* send only the modified parts to watchers
BC: charging model?
ML: requirements coming from 3GPP
JP: more reviewers needed for these drafts