2.1.12 SIP for Instant Messaging and Presence Leveraging (simple)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01


Robert Sparks <rsparks@dynamicsoft.com>
Jon Peterson <jon.peterson@level3.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:

Patrik 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

No Current Internet-Drafts
No Request For Comments

Current Meeting Report

SIMPLE - SIP for Instant Messaging and Presence Leveraging Extensions

IETF 50, Mar 22 2001, Minneapolis Min

Jon Peterson:

Agenda bashing
Blue Sheets / Minute taker
WG Status and Deliverables
Open issues discussion

Jonathan Lennox volunteered to take minutes

WG Status:
SIMPLE is now a WG
We have deliverables
They're coming up soon (Mar/May '01)

JR: These weren't insane dates when the charter was submitted, but the process took five months

Two deliverables: IM, Presence
Neither draft is a WG draft currently (WG wasn't a group until after the deadline)

Robert Sparks: Open issues

Summary of Discussions (details of each discussion are later in this text)

* Discussed issues concerning where pres: and im: URLs can appear in SIP messages.
Result : More discussion needed on list.

* Should Message sessions be bounded with INVITE/BYE?
Result : Need seen for both "chat"-like sessions and sessionless "pages". Rough agreement that we should work towards a session of messages, since a character stream session is already defined by plain SIP. Discussion moved to list with highest priority.

* Is REGISTER the right mechanism for publishing presence documents?
Result : Rough agreement that there were problems with using REGISTER. A mechanism with well defined semantics is needed. Discussion of the details of that mechanism was sent to the list.

* How do we obtain Authorizations for subscriptions?
Result : QAUTH has fatal flaws. An alternative involving subscribing to subscription state, using a separate event package, was proposed. Rough agreement to pursue the proposal. Identified a distinction between publishing full authorization policy vs a single decision. Problem identified with authorizing Fetch requests. Discussion moved to list.

* Should we Rate limit notify in the presence package?
Result : Consensus - We will not attempt to solve this now. This
doesn't prevent us adding the feature in the future.

* Is the lowest common denominator for a Message body text/plain or message/cpim?
Result : Consensus - An implementaion MUST be able to receive message/cpim, and MAY send only text/plain.

* Can a Message response contain a body?
Result : Consensus - No. This will break cpim.

* How does migration of notify responsibility interact with Record-Route?
Result : More list discussion needed.

* Other issues discussed briefly - more list discussion needed
- Addressing congestion control: Using TCP may satisfy requirement
- Spec should clarify use of Accept
- Can we reduce the state a cpim boundary/gateway must maintain?
- Does it make sense to have a message with no body?

Details of discussion

What are the ramificaitons of mixing pres:, im: and sip: URLs? Request-URI, To: and From:, To: in REGISTER, Contact: in general (R/RR), Contact: in REGISTER

JR: IMPP is also still sorting this out, hard to figure out. The right way to use these things is abstract names that sit above a SIP system. Most things that need SIP urls in a proxy network will still have sip: URLs. In SUBSCRIBE, To and From may have pres: URLs. Request-URI will almost always be SIP, To: in REGISTER, Contact...

Henning: As much as we can, keep other URLs out of it. Like tel: and h323:, not clear who finds translater, where it's found, etc. Not clear what address format is behind pres: and im:, it'd be unhelpful if two entities which were different, had same thing behind URL. If a provider offers services, make sure don't have different databases for different ones, assign same ID for different identifiers.

JR: Even in IMPP, most people not tracking these issues. pres:jdrosen@dynamicsoft.com, im:jdrosen@dynamicsoft.com. Even easier to identify than tel URLs. If I'm a client tool, I click on a pres: URL, I convert to a SIP URL locally. I'm not sure you see a pres: URL in a Request-URI.

Christian: You're suggesting it's purely a UI issue, in system it's purely SIP. I'm not so sure, what about gateways. I believe we'll see many URL schemes. I think there will be innovation in this domain. Companies have this function proposed in five different ways. Question is: what does a SIP device do when it encounters a URL it doesn't understand? That's the question we need to solve.

JR: Spec already says what to do.

Henning: My concern is for registration. There, we get into the special-case scenario. Registrar has to recognize that sip:foo@bar, pres:foo@bar are the same, but other URLs (like tel) are different; can't just do string comparisons, or strip schemes. Nightmare. We should get out of doing this -- it just won't work.

Sean: I disagree, I see no reason to limit it in this case. If someone registers with a pres:, that's what they're known as, I wouldn't do anything more complex. Either you say in the spec that pres->sip is just change the scheme, or it's more complicated to this.

Henning: as soon as you say it's a semantic difference, it gets complex.

Sean: it could be semanticaly different.

Robert Sparks: I think we've framed the discussion so we can make that distinction

Vasilis: I want to make a point, pres: can be more general than sip: URI, it can collect presence from several sources (e.g. SS7 networks)

Robert: this is one of the first discussions I'd like to have on the list. What we do when we hit a gateway, in particular.

Robert: (new slide)
Should we have a message session bounded with INVITE/BYE?

We could set up a session that uses RTP, we can set up a session that uses SIP MESSAGE outside RTP, whatever we do we need to make it possible to cross a CPIM boundary.

Hand over to JR.

JR: messaging: session or not?
Messaging has a dual nature. To some degree it's asynchronous. I send a message into the blue, it gets there, nothing more -- like e-mail. But for a lot of messages, there is a context, a thread -- UI collects all the messages. Duality to the service. I think there's a lot of benefit toward the session view of messaging.

Example: here's an example with the current MESSAGE method. I send a message to a user, it shows up at three PCs, there's no way to carry out separate conversations with the three users. But with INVITE, we can just do this, forking works fine.

This model would allow us to have messages not cross proxies. SIP proxies are signalling devices, they weren't designed to carry big messages. Vasilis has accused me of setting SIP back twenty years. We don't do this with RTP, why with IM?

With this model we can do a lot of things supported by SIP -- multiparty converencing, call controls, add messaging to voice call; more consistent with SIP.

Pushback from IESG -- large messages WILL be an issue. No sending large messages through proxies.

Existing sessions don't have a notion of a session -- can we emulate the existing GUI? Yes. I send an IM, my UI sends INVITE, recipient tool sends OK, my tool sends ACK, my tool sends message, remote tool displays message.

??: Some UIs *are* session-oriented.

JR: yes. You could do either.

Drawbacks: overhead for a single message. I think common case is multiple. Latency to set up (not as big a deal as voice). Not consistent with current implementations. Gatewaying harder? I think it's actually easier.

JL: if you hide session from a user, when do you send BYE?

JR: when user closes window, or timeout, or whatever.

Lawrence: This works for text chat, but what about SMS? Works for that, but not clear for SMS.

JR: I'll deal with this.

How is messaging session done?

Approach I: SIP stream. Treat SIP as a stream also, like RTP. SDP has an m line with a mime type message. Port is 5060 or whateverk "payload type" is SIP, send SIP messages directly beween end points. Issue: NAT/FW

Approach II: New messaging format: CPIM over TCP? Wouldn't need MESSAGE method

Approach III: RFC 2793 (text over RTP), I don't think it's the same user experience, I don't think it's the right answer.

Robert: can't get through CPIM boundary.

Hgs: for low-speed devices, where entry is slow, it's nice to be able to see what people type as they type

JR: we already have this, don't need to tell people not to do it.

Adam Roach: not a solution to this problem, but it's a different nice thing you can do.

JR: What about session-less? We can still have this, no INVITE semantics, no session much more like what things like SMS are today. Like OPTIONS.

??: GSM MAP or IS-41 MAP to transfer messgaes doesn't work, commercial success, but overburdened signalling network, needed to create separate message network.

JR: Here, you can have your cake and eat it too. We can send short messages over signalling network, or not, clean transition between to if you like.

Vasilis: Yes, but if you start with bad practice, difficult for carriers to move from one to the other.

JR: yes. You need to have guidelines in the document for when you move from one to the other, but I think it's useful to have both.

Christian: MESSAGE as it's defined right now is an INVITE without an SDP payload. One of the things you can do with an INVITE right now is to put a Subject in the message. There is a risk of people overloading the infrastructure, but if we don't allow it people will do it anyway, in a dirtier way.

JR: It's all about documenting the best practice.

Christian: I've been advocating this for six months.

JR: Yes, I've been a luddite.

Christian: Two kinds of push-back. Using signalling infrastructure helps with firewall traversal; and it doesn't actually overload the infrastructure since you can use redirect and contact addresses.

JR: Yes, see my next slides.

Pete: I've got one model that doesn't fit into either of these ways of approaching it. E.g. getting pages of stock prices. If you do sessions, it's not clear when teardown occurs. If you do it sessionless, you get into overload. It's not clear this addresses this model.

Christian: other point -- there's way more than one messaging model. With INVITE model, you get an explosion of various ways of doing things. Application-dependent -- can be good, but hurts interoperability.

JR: trade-off between flexibility and interoperability. SIP walks this line very finely.

Christian: possible to say this is a message, part of a session.

Pete: I think Christian's stated my worry.

JR: another option is to send content through URLs, if you don't know whether the client can make use of the content.

Vasilis: In my opinion instant messaging is a separate type of protocol, I think what you're describing is a PUSH/notification service, which is different. I would like to make the distinction between IM and push.

Pete: if you give people a hammer, they'll whack themselves in the head with it. If you create this, people will use this for things we didn't expect it.

JR: everything's a push protocol if you look at it at a high enough level. I don't see the difference between sending someone a message, and inviting them to a call.

Vasilis: yes, but you have to negotiate screen sizes.

JR: comparisons. SIP stream has greatest flexibility; you don't have to have two different ways to represent same data; makes it easy to do all the things we want. Second choice is new stream protocol, not terribly appealing.

Henning: since you're sending a complete message, does allow forwarding/aggregation. Not sure this is good or bad. Confusing if we copy from one or the other, message in message stream is different from signalling stream.

JR: can just offer SIP port on recieve side, bind to 5060, don't need to be able to tell the difference.

I don't think RTP approach is really viable.

Advantage of using SIP network: deals with NAT/FW. Message stream: NAT on one side, solves problem, just let TCP connection flow.

Use of SIP MESSAGE method as stream can solve other cases; send to bottom Route set, etc. Another possibility is route set in SDP. [General hum: no, no, yuck.]

I think this is the biggest issue, everything else depends on this.

Vasilis: question: You're saying initiate the session, and then use SIP as the streaming. Does it go through the proxy again?

JR: no, except for NAT/FW.

Vasilis: why not just use TCP or HTTP.

JR: I am suggesting TCP. I don't think HTTP is a good idea, this is a more peer-like protocol.

Vasilis: there are already mobile clients with HTTP clients/servers.

Jon Peterson: one possibility you raised is to invent something from scratch.

JR: advantage to using SIP -- we already have relays, they're called proxies.

Sean: I'm happy to have stream approach, but we should also have one-shot method as well, for small sessions/clients.

Jon P.: does that suggest that MUST support message, MAY support stream?

Sean: no.

Vasilis: I don't like the use of the word 'streaming'; but also be careful because IESG already said we don't want large messages through proxies.

Robert: take this to the ML. I think this is appropriately flamed -- framed! [Laughter]

What about CPIM boundary?

JR: Is there a CPIM instant messaging map? In doing the presence one, the difficulties is to know when to get rid of it, when to have it. If you just wrap this thing in INVITE. As long as you have frame-bounded thing, its easy.

We need to resolve this *fast*. Everything else depends on this.

Robert Sparks: Question in both drafts: is REGISTER the right PUBLISH mechanism? Can derive a presence document from registration...is REGISTER the right way to get it into the system from an endpoint?

JR: let me provide clarification. We've been saying all along that my presence is composed of information from lots of different sources, composed in backends. REGISTER is one source, not the only one. Plug in other sources, not necessarily SIP. Question: if I want to upload a document that describes my presence, is REGISTER the right way to do this? Similar to uploading CPL. I've become sketchy on using REGISTER for this. Problem: there are two things that can fail independently -- upload a CPL, can fail either because the contacts have a problem, or because the CPL does. I think there should be a separate mechanism -- similar to how BYE/Also was split into REFER/BYE so they can fail independently.

Henning: the problem is it's another special-purpose method -- it has REGISTER semantics, addressed to registrar rather than delivered to end system.

Sean: SERVICE mechanism?

JR: No, no, not a good idea. YOu have to have an explicit model for what this means. Mechanism for sending subscriber data to database that proxy can access. Can't just be a general "stuff" mechanism, need semantics.

Robert Sparks: have to separate providing routing information with REGISTER with other mechanisms, need to distinguish failure mechanisms.

Vasilis: when you power on, you do two methods instead of one.

Henning: you could define REGISTER without contacts.

JR: then it's not REGISTER anymore. We have guidelines.

Robert: new issue: Authorization. (This will probably take all day.) How do we get authorization from an entity, not in machine-time. Hand over to Jonathan.

JR: We know for presence we MUST be able to authorize subscriber by finding out from presentity whether it's okay. You can always have ACLs for specific people, but if we don't have it you need to be able to ask the user. First version of presence draft had QAUTH -- it always made me queasy. Review how it works. When I turn on, I send a registration with a parameter that says "this supports QAUTH". When a subscription comes in, it sends 202 and sends QAUTH and asks, "is this okay, or not"? Problem is it's an overload: uses registrations to imply ability to make authorization decisions - dangerous to overload. E.g. you have a generic registrations.

Also, want to support multiple users that can set policy. Because we use QAUTH, QAUTH can fork. Problem is that for non-INVITE, only one 200 response is delivered. Badly broken! Need to collect all responses.

Another problem -- transaction in process while waiting for user.
What if user is away? Transaction will time out.

New proposal: my subscription state is itself a subscribable entity. Watcherinfo -- I can subscribe to it. A presentity like any other. Watcherinfo maintains state for users with active or pending subscriptions.

Dave Oran: what about infinite recursion?

JR: policy for who's allowed to subscribe to watcherinfo is static -- only presentity themselves or administrator.

Robert Sparks: this could be a separate event package.

JR: when the subscriber of watcherinfo sees subscription state has changed, they can push a new policy document to the server. Notified PUSH.

flow: SUBUBSCRIBE -> 202, generates NOTIFY watcherinfo, upload policy.

Advantages: who can upload policy has nothing to do with registrations. Determined by who can send upload messages.

I can receive notifications about subscriptions without sending poicy.

Multiple entities can authorize.

Dave Oran: this doesn't work for any arbitrary policy merge. If multiple users upload policies, can't me merged in consistent fashion (e.g. classic ACLs). Does anyone find out there was an error, and how are errors of upload handled? Is it just first one wins?

JR: it's flexible.

Dave: that's the problem.

JR: only one user can upload policy -- presentity. Just replaces.

Henning: not fundamentally different from forking problem with QAUTH.

I subscribe to watcherinfo from two different places (have to, or bad things can happen). I get two notifications for change of watcherinfo. This means that one can say yes, and one say no.

There are half-a-dozen policies you can do.

Dave: Is what you send a decision, or a policy map? Get notification 'Bob wants to subscribe'. I can respond with 'Bob's allowed, Sue's allowed, Joe's allowed.' QAUTH doesn't have merge problem.

JR: problem exists anyway. Have to reconcile with offline policy.

Henning: You have to be very careful what policy document is. Several notifications happen in sequence; if you believe in complete state, what happens.

JR: I don't think complete state is a good idea.

Henning: do you want to be notified for renewals?

JR: no. No change to watcherinfo.

(Continuing with slide) multiple entites can upload policy -- server can reconcile (but we need to figure out how). Unifies triggered and untriggered policy -- cleanness if we have one way to do this rather than two.

Vasilis: [question I didn't entirely understand...] What's you definition of policy?

JR: it's a list, "allow bob, don't allow joe". Or pieces.

Vasilis: where is reconciliation?

JR: in the server.

Vasilis: in the device, or in the presence server?

JR: doesn't matter. It's a logical role.

Vasilis: can you have multiple PAs?

JR: no.

Dave: in the QAUTH scheme there's transactional state, here there isn't. But if you want to maintain causal ordering, the server has to maintain the equivalent of transaction state. Joe tries to subscribe, Sue tries to subscribe, notifications cross. Decision as to what to push back is causally depentant on what other transactions completed. First one says "allow bob, not sue". Second one says "allow bob, disallow dave".

JR: I don't see why it matters. As long as I can go to a webpage and do it, it doesn't make any difference.

Dave: I'll take it off line. I'm just pointing out there are complicated merge issues that aren't addressed here.

JR: I'd like to know what they are.

Henning: we haven't specified policy mechanisms, but it's clear there are some mechanisms that don't fit here without careful thought. It has to be composable at a syntactic level with reasonable action. Also, policies have to have time associated -- "this person can't subscribe right now, but can a minute from now" up to "this person can never subscribe." E.g. work vs. home subscriptions.

JR: we can separate this -- keep it simple at first, then update independently of subscription stuff.

Henning: Also, anything we don't say about remains in pending state

Eric Hauper: I don't think this will work, I don't think any automated query is at all reasonable. I think that subscription is a special message sent to the user -- will you allow me to subscribe to you?

JR: you're mixing implementation and service. What is it you want from a service perspective?

Eric: I think the server shouldn't get involved in this at all, other than queueing up messages. The server shouldn't get involve in people trying to subscribe to a presence that doesn't exist in the ACL.

JR: this model would allow that approach.

Eric: I don't think it should be triggered on a subscription at all.

JR: that's how it works now with existing systems. I know at least Yahoo works this way.

Eric: I don't think the server should have a concept of this.

JR: send something to the list that explains this problem. I'm hesitant to understand the problem.

Theo Kalvinis(sp?): I agree with this proposal. I also note the presence server is hiding the subscription. Always give back answer "Noted".

JR: yes, -01 does this: Always generates 202, fake notify, you can't tell this is happening.

Theo: what happens on fetch?

JR: if I have an ACL that allows you, it works...have to think about other case.

Robert Sparks: there's a problem there, need to take it to the list.

Point in general: when I made a call for open issues, I wish that had been raised then. Raise open issues to the list when they occur to you.

Vasilis: big issue, how do you handle pending subscriptions, CPIM doesn't say anything about this. I think we can resolve this in IMPP, not here.

JR: problem isn't what subscribers say, it's how it relates to authorization. If you never know someone try to subscribe.

Theo(?): one more potential issue, if entity A and entity B have distinct domains/servers. If I'm B and I want to subscribe to A, whose presence server do I go to?

JR: A's.

Theo: what if two people want to be bob@domain-A.com?

JR: don't do that.

JL: I think policy info should be subscribable.

JR: too complicated.

(Continuing with slide)

What if someone subscribes when I'm offline?

I log in, fetch watcherinfo, approve pending subscription sif we want.

How do we do it?
* event package for watcherinfo (Patrick says okay to do in SIMPLE, needed for presence)
* watcher info data format (in NOTIFY of watcherinfo) (had one in original June 2000 drafts)
* policy document - document is a good idea - can share it, store it, generate it by servlets, universal intermediate usage like CPL
* How do we upload it?

Proposal: define something new, update JL's register upload for new method (setdata?). Not done in SIMPLE.

I think this is the second-biggest issue. If you have better idea, mention it, I'm not wedded to this, but we need something, and I think it's better than QAUTH.

Robert Sparks:
Should we rate-limit NOTIFY? Sip-events punted, sent it off to event packages. We have an event package, what do we want to do?

JR: I don't think so, let's keep it simple, it's not like this happens frequently.

Robert: for presence for people, some people are trying to do this. GEOLOC.

Henning: it's probably not that effective. What you worry about is total inbound sender rate, you can only limit one. Hard to do client control on server side. Server side is probably more substantial load, e.g. sending info to thousands of subscribers.

Robert: agree that for first pass, we may not need to solve it. But if we don't solve it, are we closing the door to solving it later?

Henning: I don't think so, it's just a parameter. More general problem: subscriptions are unqualified -- "I want to hear from you" or "I don't want to hear from you". Can't do something more finer-grained. I think rate limitations are just a part of this, which we want to do later.

Robert Sparks: so I propose that unless someone says something, let's just leave it undefined for now.

JR: current subscription document says that subscription body can contain TBD subscription filter.

Robert Sparks: next issue:
is lowest common denominator message/cpim or text/plain?
For e-e across cpim boundary need to do message/cpim.
Some agents may not care.

JR: careful. For sending, can say don't care. For recieving, what if APEX user wants to send message/cpim? I think MUST receive m/cpim, MAY send it.

Ben Campbell: do we want to say that all our devices must be CPIM compliant? Is it okay to have a simple end system that can't cross CPIM?

Henning: you can rule it out all you want, it won't matter. It's a complicated spec, people will do subsets.

JR: that's always the case. I think the answer from the ADs is that the spec has to be CPIM-compliant. I can't control implementations.

Henning: if it's an authenticated message, the gateway could convert it, losing authentication. In general, we can't verify that end system can verify authentication anyway. Need PKI, need common root certificate.

JR: I don't think that's an excuse not to allow for interoperable authentication end-to-end.

Henning: could specify in caller preferences.

JR: gateway isn't necessarily your registrar.

JL: could say that just require multipart/alternative, gateways provide both text/plain and message/cpim.

Vasilis: How do we make this decision?

Robert: on the list.

Ben: don't take this as a criticism of interoperability.

Robert: I think we have consensus for MUST receive message/cpim, MAY send text/plain.

(skip some slides, then:)
Question: what does a body in a 200 OK to a MESSAGE mean? Is it a reply?

JR: it's broken to do this, can't maintain ordering.

Robert: so say MUST NOT include body in response.

Henning: raises issue -- if you do streaming of SIP MESSAGES, do you still do 200?

JR: yes.

Robert: (new issue)
How do you synthesize presence document from reigstered data?

JR: this is dependent on CPIM presence format.

Robert: (new issue)
How do you interact route/record-route and migration of notify responsibility?

JR: Migration only on new subscriptions. Special-casing route/record-route is very bad.

Christian: It's not clear that R/RR makes sense for non-INVITE messages anyway. Why do you want to record-route subscription?

JR: various services, e.g. firewall traversal

Christian: I want to disallow r-r in subscribe.

Robert: this will require more list chewing.

(new issue)
Can we reduce state that gateway must maintain? cpim doesn't reflect call-leg semantic.
Point out: no such thing as cpim-on-the-wire, maybe can translate state into state in other people.

JL: can we do the opposite, provide state for other protocols?

Robert: it'd be nice.

(new issue)
Does it make sense to have MESSAGE with no body?
[general muttering]

(new issue)
Should we say that accept means mime type inside message/cpim

JR: yes.

Other issues:
Congestion control, map to CPIM

JR: If we do streaming over TCP, problem goes away.

Christian: no it doesn't. If I'm in conference mode, maybe many TCP sessions.

JonP: I think it's sufficient.

RS: we made it through slides, one minute over, take remaining issues to list!


SIMPLE Open Issues
IM and PRES open issues