SIMPLE Notes
reported by Dean Willis
1540 21Mar06
Agenda presented and accepted
Topic: Status
reviewed by chairs
Slides presented.
Noted that XCAP and numerous other documents are approaching WGLC and people need to be ready to perform reviews.
Topic: XML Patch Ops and XML Diff
Led by Jari Urpalienen
Slides presented.
All documents believed ready for WGLC
Topic: SIMPLE Multiparty Chat
led by Aki Niemi
Slides presented.
Background reviewed.
Changes since -03 reviewed, including complete rewrite, elimination of distsend, and sub namespaces within conference for nicknames.
Issue: Nicknames. Suggested that XCON technique might be preferred path. However, this loses anonymity property, which could push a change requirement back to XCON. Suggested also that this is a very general requirement and needs to go beyond chat.
Issue: Authorization policy has dependency on XCON. Suggested we let XCON get this done instead of reinventing.
Issue: OMA Dependency. Noted that OMA has very near-term requirements and is likely to do something, even if it is wrong.
Discussion: Should we continue in current track, do something interim, or do something experimental?
Several proposals offered by presenter. Rohan offered an alternative -- do everything in XCON. Argued that temporary solutions would be a bad idea. Of course, we could always use INFO . . .
Aki noted that there's a lot of XCON that we do NOT need for chat, such as floor control.
Adam noted that many protocols do all these chat features. Why should we copy? Also, that there are four or five different problems here, and perhaps we can deal with those individually.
1) Aliases/Nicknames
2) Sending messages to a subset that is not a sidebar
3) Policy
4) Sidebars
5) Message history
Ben declared that statements like "anonymity is needed for chat but not conference" are disturbing, and most requirements reply to both or neither, and that most of this work should be in XCON.
Mary further agreed that work is starting in XCON and needs more feedback, and that we should not be solving this problem in two places.
This repeated in circles for awhile, with Aki maintaining that chat shouldn't have to wait to xcon.
Jonathan noted that having a "message history" fast-forward on conference calls would be handy, and this isn't just a "chat" feature.
How would a 2nd solution coexist with xcon?
Markus suggests that nicknames are a generic feature but that private-chat might be media-specific.
Question: Should OMA use XMPP instead of MSRP for text messaging? Noted that if it meets their requirements, yes. However, they may well have unvoiced integration requirements around conferencing, so XMPP might not.
Noted by Mary that further development will not break XCON, but might waste time.
Chair summarized that:
1) There is agreement that nicknames are important.
2) There is interest in solving this problem somewhere.
3) We seem to favor solving nicknames in XCON over doing it here.
4) We need to liase to OMA giving them status, and suggesting that if they do ANYTHING, it should NOT be the previous version of this draft.
Do we want to dump this whole thing (except for the MSRP specific stuff -- move the signaling plane part ) into XCON? Consensus: yes.
(Chair edit for clarification: The room consensus was to split the current draft into components. Most of those would move into XCON drafts. Those parts focusing on the use of MSRP will continue in SIMPLE. - RjS)
Topic: Summary of Instant Messaging Requirements
led by Hisham Khartabil
Slides presented.
Do we want to adopt all or part of the expired draft-rosenberg-simple-messaging-requirements as a working group item?
A design team will meet in Thursday. Hisham wishes the current meeting to produce requirements that the design team will pursue.
Discussion on Requirements. Do we want to work on the presented requirements? Jonathan noted no intent to continue the extant document, needs a new editor. Sean noted that IMDN may not be needed, except in conferencing case, which possibly isn't covered by the current draft. Ben supports requirements in general, but wonders if we should re-examine the requirements draft for stale bits. This led to a discussion relating presence to messaging session liveness. Aki suggests an "is-live" event package and maybe an "is-focus" event package.
CHAIR POLLS TO REPEAT ON LIST:
1) Who thinks IMDN is ok but don't really care?
2) Who thinks IMDN is important?
3) Who thinks important but not working on it?
4) Who wants somebody else to work on it?
5) Who thinks IMDN is evil?
6) How many people now have time to work on IMDN? (1)
Overall, the group believes IMDN is important and wants to work on it but have been busy on other things and might not be able to work on it now.
What else would we work on besides the requirements listed here? Need a short round to see if we've missed anything.
POLL: Do we need to spend effort on invitation to non-real-time sessions (noted: nobody wants it).
Is there anything else to work on?
Noted that we may need to rescue the "msrp send" part of the extant chat draft, and work on it.
Who will take leadership on requirements document rebirth? Chairs will have design team attack it.
In light of hums and pairing down, is the charter of the design group to analyze the requirements? Yes, the first step of the design group is to put a new document in front of the WG that will say what they will be working on -- that is, they will propose a new requirements document for review.
Question: How to put all this together? We have MESSAGE, we have MSRP, when do you use which one?
Topic: PIDFConn
led by Erkki Harjula
Slides presented.
Changes since -01 reviewed.
Question on Range Attribute: Known that theoretical throughput on US academic network may be 2 orders of magnitude removed from real throughput. This information is not usefully accurate, We need either more accurate information or at least more accurate labeling of the information.
Noted that the e2e model requires measuring to a certain watcher, and is highly dynamic. Discussion followed that e2e information is unlikely to be useful, and even local information is only sort of occasionally useful as an upper-bound if you get lucky.
Rohan suggested that the bandwidth stuff should be scoped to just a number.
Discussion of open issues: none followed.
Polls:
1) Is this problem worth addressing in this WG?
Consensus: No.
2) Is this draft an acceptable first effort towards doing this work in this WG?
Never mind.
3) Do we want a milestone for this work?
Never mind.
Topic: XCAP Profile
led by Rohan Mahy
No slides presented.
Previous feedback suggested that the draft was useful as an optimization trick. The draft was revised to reflect this. Two comments have been received on list since. The profile is not a profile of XCAP, rather it is a profile of two usages of the XCP protocol. Also, the current validation shortcut doesn't work with namespaces, requiring xml-fragments.
How does a UA know it can use this? The UA can always use it -- there are no server requirements. These are just common-sense lazy usages of XCAP.
A couple of people still care. Author chooses to abandon the draft.
Topic: Outstanding Charter Milestones
led by Robert Sparks
Slides presented
1) CPIM mapping: Argued that no customer exists. AD seems to agree, but suggests it is appropriate as an IESG discussion. Noted that Jabber might have used this mapping, but they ended up doing a direct XMPP to SIMPLE map without the CPIM intermediary. Consensus is that this work may be of negative (not zero) value. Question: Does this drive other work, like not using CPIM mappings in messages? This mapping document was only an abstract presence-concept mapping exercise, not a mapping to CPIM document formats, and it turns out that all presence systems seem to inherently meet the CPIM fundamentals. Question: Does sending a message/cpim body to a XMPP gateway add value? Currently, no. If we ever do anything that exercises CPIM, like sidebarring in XCON, maybe. Noted that we have used characteristics of CPIM bodies that has nothing to do with the CPIM mapping model.
2) Advanced messaging requirements: Nope. (Chair edit: Refer to the Messaging requirements discussion earlier in the meeting - RjS)
3) SIMPLE architecture chat: Suggested: lesser value than other activities. Wouldn't block somebody from doing it. Still see lots of questions about page mode vs session mode and large messages. Proposed that we could instead do a hitchiker's guide? Rohan requests guidance on usefulness of his related work.
Noted that there will be new people looking at presence and IM, and it might be useful to have a articulated model for them to look at.
Jon noted that original mission could probably be achieved by an annotated guide.
Issue: Composition? Easily defined to be unsolvable. Can a solvable subset that is still interesting be defined? Henning is aware of work proceeding in this area that might prove useful. (Chair edit: We have a draft (presence-processing) that has been tabled awaiting discussion. Jonathan agreed to bring it back to the foreground - RjS).
Question? What is missing?
Noted that we sometimes discuss "presence peering" and cross-site or cross-server subscription optimization. Is there something there?
Strawman milestones presented.
Noted that IMDN has bifurcated and June is an aggressive date.
Is there are a category for future enhancements for presence, like status searching? We can consider these when people bring them in as actionable ideas.