Subject: [Simple] Draft minutes SIMPLE meeting IETF52

From: Robert Sparks <[email-masked]>
Date: Wed, 9 Jan 2002 11:13:04 -0500

Here is a draft of the simple minutes for IETF52.
Please review and submit corrections before Friday 1/11.

RjS

-------------
SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions
Minutes - 12/12/2001 1300-1500 MDT - IETF52
Chairs: Jon Peterson - [email-masked]
        Robert Sparks - [email-masked]

Summary:

Charter and logistics

* An update to the SIMPLE charter has been submitted
  reflecting the SIP/SIPPING split, the proposed SIP
  change process, and the watcherinfo/CPIM mapping
  deliverables. Publication has been tabled pending
  outcome of disussions in SIPPING (see the SIPPING
  minutes)

* MESSAGE has been handed off to SIP - currently 
  scheduled for last call in May. Brian Rosen will
  work with us to move that call to an earlier date

draft-ietf-simple-presence:

* The presence draft will be modified to rely directly
  on sip-events, which will in turn rely on sip-bis 
  instead of 2543. The result will be shorter documents
  with less opportunity for unintentional contradiction.

* We will provide Alerts (notification with indirect content).
  Primary remaining issue: Lifetime of URI in an Alert.
  Both the sip-events and presence drafts will have to change
  to reflect this.

* There is consensus to establish a presence subscription
  dialog based on the first arriving NOTIFY or 2xx response
  to the SUBSCRIBE

* There is consensus to leave the current forking
  text as is. Subscribers SHOULD accept only one
  NOTIFY. If merging is required, the burden lies
  on the subscriber.

draft-ietf-simple-winfo-package:
draft-ietf-simple-winfo-format:

* Proposed recent format changes accepted with
  the additional removal of most-recently-subscribed

* Sip-events and the format draft will reconcile the
  descriptions of reasons for terminating subscriptions

draft-mankin-im-session-guide:

* Hum against taking this on as a SIMPLE work item
  Opinion was that work on the draft should continue
  in the transport area

* SIMPLE group urged to internalize its guidelines

* Applicability of the requirements being placed on OPES
  wrt intermediary discovery and disclosure needs to be
  discussed

draft-rosenberg-simple-im-transport:

* Weakly expressed support. Moderately strong hum against
  proceeding with this proposal.
  - concerns over keeping IMTP and SIP syncronized
  
* Alternate proposal solicited - if none appears before
  early January, work will proceed with IMTP

* Split opinions on whether a proposal must be held to 
  mankin-im-session-guide

--------------------------------------------------------------------- 
Full Notes (thanks to Brian Stucker - [email-masked]) 

Charter Updates: 
Have submitted a new charter. 
* Charter resubmitted a couple of weeks ago 
* Now reflects SIP/SIPPING split and proposed SIP change process. 
* Presence 'extension' deliverable now 'event package and related 
protocol mechanisms' 
* Presence publication tabled in SIMPLE, currently considered in 
SIPPING. 
* Dec 01- Presence event package, watcherinfo, CPIM mapping. 
* Jan 02 - Messaging drafts 
Transferred deliverables 
* Draft-ietf-simple-im-01/draft-ietf-sip-message-00 
  - Status (any SIP chairs want to speak to schedule?) 
  - SIP drafts page say May 02 - be nice if that could be moved in a 
bit. 
    * Brian Rosen: Drafts dates are based on logistics problems. We can 
move it up if we can get the draft ready, get reviewers, list comment, 
etc. But we can move it up if there is a need? 
    * Jon: Would be nice if we could have this in the first quarter? 
    * Brian: We'll look into it. 
* Draft-donovan-publish-requirements-01 
  - An actual proposal discussed in SIPPING yesterday. 
  - Clear that SIPPING will only do requirements for publication. 
    * Where will it go from there? SIP WG? 
    * The IETF would like to do the right thing, and not get too rule 
bound. Hope is that the same people will spend some time in SIPPING and 
make sure that the right approach is formed.  The method document has 
to come out of SIP. 
    * SIPPING needs to look at the problem of whether or not we need a 
new method. 
    * Question begs, is presence publication urgently needed in SIMPLE, 
and that needs to be looked into. 

------------------------------------ 

Presence Open Issues: 
* Open issues in presence-04 
  - Dependencies and duplication 
    * Currently 
      - Rfc-2543 <- sip events <- presence 
      - Problem is that sip events is duplicating text from bis-05. 
        * Can we simply make sip events dependent on bis, 
          thereby shortening it. 
      - Presence is duplicating text from sip events. 
    * Proposal 
      - Bis <- sip events <- presence 
        * Bis is nearing completion so timing is not going to be 
          much different 
        * Requires cleanup of redundant text across all three documents
          in progress. This will be done. 
  - Alerts 
    * Would be nice to only be notified of change in presence, not 
      actual presence. 
    * Actual presence could then be fetched with HTTP 
    * Why is this useful? 
      - Large presence documents wouldn't get fragmented. 
      - Large presence docs could be fetched when time is good 
        (ie. Not in a call). 
    * Details 
      - SUBSCRIBE would have Accept header indicate support 
      - Presence of application/uri-list 
      - Still have to support application/cpim-pidf+xml 
      - Etc 
    * Issues with Alerts 
      - Broader than presence. Probably belongs in sip-events 
        * Presence would then state that its allowed. 
      - Security issues 
        * Just because SIP can be authenticated, doesn't mean HTTP can. 
          - Transitive trust vs. e2e 
          - Henning brought up concerns on this. 
      - HTTP SIP interactions 
        * Requires a way for SIP server to manipulate content on web server.

          - Henning brought up concerns on this. 
      - Duration of URL validity 
        * Need to specify - presumably subscription duration. 
    * Proposal 
      - Really useful, really simple 
      - Add to sip-events and presence. 

Henning: Similar to web server problem. 
Jonathan: does require an interaction between HTTP and SIP; don't 
have to do it. 
Henning: Must specify something that will work well. 
Brian: Doesn't have to be HTTP, could use other mechanisms. 
Jonathan: Must develop a baseline. 

Call for opinions: 
Sean: I don't see this as a major issue, or a hard thing to do. 
Adam: I'm in support for this, I don't see a problem. The issues 
that Henning brings up are not completely trivial, but they're 
easy to take care of.  Can be added to sip-events, but doesn't 
see a need. 
Rosenberg: Wants a general mechanism the same across all packages 
and to specify behaviors. Need to specify the duration that the 
presence URL is good for. 
Sean/Rohan: Don't go into such detail about the implementation. 
It's unimportant how long the document sticks around. 
Henning: We need to make sure that the semantics are complete and 
equivalent. 
Brian Stucker: Agrees that need to specify amount of time for URL 
to be valid, just as there is one for subscription. Interval 
doesn't need to be specified. 
Sean: There's no guarantee that the semantics are equivalent. 
Adam: This sounds like the argument about how to encode a piece 
of content versus what it means. 
Rosenberg: This is an automata that is processing this URL, so it 
needs to have an idea of how long the URL is good for. 
Jon: Is there any value in leaving this URL open for our 
application? 
Rohan: I don't think that's what Rosenberg is proposing. 
Diana: Likes the consistiency. Does this trickle to general SIP? 
Henning: The semantics that we are arguing about here are buyer 
beware problems. This is a presence document, versus this 
document is not going to be around after a period of time. We 
wouldn't specify that this is a presence document, we're 
specifying other attributes. 
Adam: I don't have a problem with the proposal, but it sounds 
like the semantics of the usage should be in the presence 
document. 
Jonathan: Need to specify what URL means and have well-defined 
semantics to work. 
Henning: sending a JPEG isn't particularly useful. 
Sean: Your implementation has to handle it - doesn't need 
standardization. 
Adam: How is content encoded Vs. what does it mean? 
Jonathan: Wants to define what it means when you return a URL. 
It's important to remember that a person isn't using this URI, 
an automata is.  
Andrew: This is like W3C semantic web problem. 
Jonathan: Disagree - not solving that problem 
Jon: What do we want the Presence URI to mean? 
Rohan: That's not what Jonathan is proposing. 
Henning: 2 issues: what are the time properties and what is the 
content.  In events, this would not be a presence document.  
The semantics being argued are hints to the implementor - these 
are the semantic expectations.   Agree that semantics need to 
be specified. 
Jonathan: Most web browsers accept *.*.  This URI should be 
very specific and have full semantic content, unlike normal web 
request. 
Rosenberg: Presence package would say that this is a one-shot 
document, etc. 

Conclusion: Continue discussion on the list. 

  - NOTIFY/200 Race condition 
    * ASSUME you want to only accept one NOTIFY 
    * Sip-events says you should accept the one that matches 2xx to 
      SUBSCRIBE. 
    * Proposals 
      - Buffer NOTIFYs until 2xx, then 481 all that non-matching ones. 
      - Accept all NOTIFYs, when 2xx arrives, refersh all non-matching. 
      - Accept first NOTIFY 
        * SUB 2xx is ignored 
      - Accept first message 
        * SUB 2xx if its first 
        * NOTIFY it its first 
    * Probably also an issue for sip-events, not presence. 

  - Forking 
    * Definitely the biggest issue. 
    * Some problems are not presence specific 
      - HERFP 
    * Proposal 
      - Keep what's in the document. If they need aggregation, then put 
        a point in the network and leave it be. 
      - If there are multiple PUA, you get partial presence, no 
        guarantees. 
      - Subscribers SHOULD accept only one NOTIFY 
      - Burden is on the subscriber to implement merging if it wants. 
      - Won't generally be needed based on domain requirements and 
        frequently won't happen because HERFP. 

Conclusion: No time for discussion, taken to list. 
---------------------------------------- 
Watcherinfo Open Issues 
  - Events leading to terminated 
    * See previous discussion 
  - State maintenance for pending/waiting 
    * Possible Dos? Sub is authenticated 
    * -01 will talk about setting policy for this 
      - Tradeoff between user experience and state storage 
Stucker: isn't this just a policy issue? Why does this belong in watcher 
info? 
Rosenberg: When you have watcher subs you need to keep state for things 
being watched.  The fact that there's a watcher info on t you need a 
state. Want to specify a caution with regards to potential for attacks. 
The watcherinfo draft defines a model for presence. We shouldn't have this
in sip-events. 
Stucker: Are you going to add when to indicate when subscription is active?

Jonathan: Both have an approved.  Want these to align between 2 documents -
he's only showing error cases where they don't align

Adam: There are 2 other states: Pending and Active.  These are whys for the
failures. 
Jonathan: Should the state machine be in sip-events.  Watcher -info defines
a model; you could have much more states and a more complex state machine.  

  - Elements in data format 
    * Watcherinfo data 
      - Uri of watcher 
      - Status of subscription 
      - Event which triggered notification 
      - Duration time in last state 
      - First-subscribed 
      - Most-recently subscribed 
      - Added: expiration 
      - Removed: Notify-address 
Chris: let's ditch most-recently subscribed, it's not very useful. 
Rosenberg: Okey-dokey. 
Rosenberg: The watcherinfo draft defines a model for presence. We 
shouldn't have this in sip-events. 
  - Status in winfo/sip events proposal on the list. 

Conclusion: No Comments (thus consensus implied) 
--------------------------------------- 
Guidelines for IM Sessions: 
  * Context: 
    - IM payloads are moving away from short-text only, towards 
      * Images 
      * Video clips 
      * Mp3 and other audio data 
      * Etc. 
      * Large populations of users meeting over shared infrastructure 
        (interconnect of AOL, MSN, etc). 
    - Sessions of Messages: 
      * SIP message is the medium. 
    - Transport Background 
      * In order of concern, reliable transport of serious amounts of 
        data raises concerns of: 
        - Congetion collapse 
          * Will congestion of the system invoke protocol actions that 
            increase data sent into the system? (1986 TCP collapse) 
        - Scope of fate-sharing 
          * Can desired end-to-end behavior and properties be achieved 
            and maintained through intermediaries? 
        - Congestion avoidance and shared effects 
          * When J users share a filled or congested path, and adapt, 
            can they get close to each having 1/Jth of capacity? 

Allison Mankin: We have to be that when we do congestion control that TCP 
adapts it's behavior to the congestion on the link. Want to be sure 
that there aren't unanticipated effects from the extremely large amount 
of traffic. 
  * Guidelines Draft 
    - Purpose is to distill transport concerns, with some related 
      architectural and security concerns. 
    - Session model 
      * When data of IM (or session of IM) is carried within headers 
        seen/modified /operated-on by intermediaries 
      * If you took the MESSAGE, without the headers, and threw it onto 
        an end-to-end TCP connection, it wouldn't create any of these
        issues. If you have UDP in the middle, you can run into 
        congestion problems. 
      * If IM clients stop off at the various intermediaries, they get 
        1/N*M bandwidth (N intermediaries, M IM clients) instead 
        of 1/M, which is a significant penalty. It's because of 
        the TCP queuing system. 

Rosenberg: This could happen for a lot of reasons. 
Allison: We don't want congestion collapse, but there are some other 
interesting things going on. 
Rosenberg: If we use TCP then this isn't our problem. 
Allison: No, the answer is that if you use TCP, don't get greedy 
with the number of intermediaries. 
Christian: There is a fundamental problem here, and it's with TCP. 
Allison: I think we still have some value to look into the transport 
dynamic, and moderate the use of intermediaries. Working on another 
paper to fully research this.  This scenario is a worst case. 

    - Multi-Intermediary protocols 
      * Diameter/Apex/Opes/SIP-SIMPLE 
    - Guidelines for Sessions 
      * Signaling MUST be able to negotiate a common underlying 
        transport 
      * MUST not use UDP because of congestion control issues. 
      * Session/transport solution SHOULD support (MUST?) specifying a 
        single transport protocol for entire session path. 
      * MUST not use multiple parallel reliable transport connections. 

David Oran: Why be so harsh, what's wrong with using UDP in a 
congestion safe way? 
Jon (summary): What we're talking about is that this is the session 
model, not setting up the session. 
Allison: Yes, this is a problem with long streams of data. 
   - Guidelines for Sessions 
     * Does design lead to a well-formed session protocol? 
       - Does the design carry the right data over aggregated 
         transport, session membership, data sequencing, 
         identification and so on? 
       - Is it designed right for the security goals? 
       - Draft-iab-opes-00.txt an RFC-t-be from IAB. 
       - Model for some more architectural guidelines: 
         * SHOULD not interpose without consent, by at least one of the 
           parties 
         * MUST support mechanism for discovery of intermediaries 
         * MUST disclose (either in signaling phase or session) the 
           intermediaries 
         * More... need to discuss in email. 

Rosenberg: The intermediaries are not there to modify the content. It's 
just there to deal with NATs, etc.  Such as in SIP. 
Allison: There is an area where the consent issue may be a bit gray. 
It's not a perfect match. 
Jon: I think we're trying to speak as to what the direction should be, 
not where intermediaries should be deployed. If the client is informed 
about what is going on, then it can take action. 
Henning: I would hesitate to draw too close a parallel on that, because 
there are properties in there that make the predictability issue a bit 
harder. There are issues with discovery and finding that we've had for 
some time. The other thing is that content modification (via headers, 
etc) doesn't necessarily match with the consent model in OPES. As long 
as these are transport entities that don't do much, then you can't 
extrapolate for OPES. 
Rosenberg: Why is this not such a problem for email? 
Allison: We're going to have to wrap up, we're running out of time. 
  * Next? 
    - End goal is for SIMPLE WG to internalize and feel ownership of 
      the guidelines 
    - Document should stay individual or be in the set of WG documents? 
Jon: we did make a good try at generalizing these issues. 
Wcom: I believe that the draft is bloated and it confuses signaling and 
transport, so let's get rid of it. 
Jon: That's unfair, we're responding to what this WG has already gotten 
itself into. 
IMPP WG chair: I don't think that this belongs in either working group. 
------------------------- 
IMTP Proposal: 
  * Motivations 
    - Requirements for IM transport 
      * Congest 
      * Reliable 
      * Arbitrary sizes 
      * Framing 
      * Per-im content typing 
      * E2e privacy, integrity, authenticity 
      * Works through nat 
      * Rapid delivery 
      * Lightweight 
      * Parser reuse 
      * Compressible 
      * Support for different content types 
      * Muxing 
      * Logging 
    - The hard configuration (PC in enterprise 1 going through a ent 1 
      proxy to internet, over to proxy in enterprise 2 to a PC in 
      enterprise 2). 
  * How about SIP? 
    - Pros: 
     * Parser reuse 
     * Proxies as intermediaries 
     * NAT traversal easy 
     * Logging, framing, sequencing all done 
    - Cons: 
     * SIP has features that would get in the way 
       - Record-routing 
       - Redirection 
       - Forking 
     * Messages might go over UDP 
     * Performance of Proxy as pure forwarding intermediary is poor. 
  * Idea: Sip Subset 
    - IMTP proper subset of SIP 
      * Remove unneeded features 
        - Forking, redirection, recursion, record-routing and route 
      * Introduce restrictions 
        - Only TCP 
      * Change protocol field to IMTP/1.0 from SIP/2.0 
        - Most proxies won't route 
        - BUT, one-liner to fix that 
        - Want this to be explicit about what protocol is running 
        - Proxy with proper configuration can route IMTP 
      * No forking, no record-routing, no redirect, TCP only 
      * Can use REGISTER to set up IMTP bindings 

Allison: How hard would it be to put in error checking so that if there 
were an inappropriate header were present it could be dealt with. 
Rosenberg: It is a minimal SIP request 
Mic: How do we specify IMTP? Where will this be done, where will 
discussion be held for this since it's a different transport protocol. 
Rosenberg: There will be a separate document for IMTP, and will go into 
this WG. It is burdensome to tie SIP and IMTP together, so let's not. 
Rosenberg: We're working on the end-to-end nature of the protocol to 
specify a key for the session to create an end-to-end solution. We can 
use that key into S/MIME so I can encrypt the content of the message 
path. 

Security:  working on SDP extensions for key exchange (MIKEY) (2 
pass)  Could use key as input to S/MIME to encrypt e2e.   Whatever 
solutions we develop for SIP would apply to IMTP. 

Andrew: What is our reaction? It's not obvious that there's not good 
engineering necessarily here, but this is what we need to do to get 
things done. 
Henry: What is the problem we're trying to solve? We have fast servers, 
we have bandwidth, so why is this a problem. 
Jonathan: Want a session model for SIP.  
Cullen: Can deal with IMTP being a profile in SIP.  Can't deal with 
divergences between the 2.  Should keep synced with SIP. 
Henning: As long as it's done by reference, then it's not as big of a 
problem. 
Rosenberg: It's not that clear, but it's not by reference. 
Dean: Either IMTP reduces to the argument against a session model or 
argues against using SIP how we're using it now.  Believes that if SIP 
as we've defined it doesn't scale then it's broke, but if it's not 
broke, then why can't it be used as is for the session MESSAGE problem.  
Rosenberg: SIP has the idea of finding the user, and the delivery of 
the content. The session model for SIP for SIP works by finding the 
user, then delivering the large data by another piece. SIP is good for 
the discovery problem and NOT good for the delivery of large data. 
Dean: I would argue that if we can't do signaling for call setup, then 
we can't do messaging, and vice versa. If you want to use a new 
protocol, why not use BEEP or another protocol? 

Rosenberg: Nobody has come forth. 
Rohan: I think we should make it so that it absolutely should not go 
through a proxy. 
David Oran: if there is anything to be gained by the MESSAGE method in 
the IMTP versus in SIP then let's converge them. I don't think it's a 
big deal with IMTP being renamed. If people think profiling is a 
reasonable way, then look at MEGACO.  Is there anything to be gained 
from the Message method in paging and the message method in session? 
People have said that it's easier. 
Dave Oran: Could you share a TCP connection with SIP? 
Jonathan: No, but you can share TCP between IMTP. 
Rosenberg: I am getting the feeling that it's not a good consensus. 
Christian: I like this proposal because it's easy to specify. Do we 
just have MESSAGE, nothing else, and enable us to do this? It's easy to 
implement, easy to undertand, etc. 
Henning: We have to solve this problem. 

Chairs consensus gathering: 

* Do we want to pursue this? Hum vote: 
  - Yes? Delayed hum.  
  - No? stronger hum. 

* Is the session model for messaging important? 
  - Yes?  Hum 
  - No? small hum. 

Rohan: Proposes that unless you get alternative proposals within a 
reasonable timeframe, that we should just go with this. 
Jon: We'll  send something out on the list, and if we don't get a 
response by the end of the holidays, we'll go with IMTP by default. 

Chairs consensus gathering: 

* If we are going to have a proposal for Sessions of messages, should 
they adhere to guidelines? 
  - Yes? Hum 
  - No? Equal hum