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