[Simple] draft minutes: SIMPLE at ietf68

Please review as soon as possible. Send comments/corrections to the  
me or the list.

Thanks,

RjS

----------------------------------------
Minutes : SIMPLE : IETF 68
March 22, 2007 - Thursday Afternoon I

Chair: Robert Sparks
Notetaker: Dean Willis

Summary:

* MSRP has been approved.

* A technical error in the IANA registration section of the IMDN  
draft has been identified and corrected. The document will not be re- 
WGLCed. Reviewers should pay special attention to this correction  
during IETF last call.

* There was interest in discussing IMDN for MSRP messages. Some  
concern was expressed over the notion of "read" vs "delivered".

* The Presence SIGCOMP dictionary will progress as an AD-sponsored  
individual submission. Several attendees volunteered to review the  
document.

* Some interest was expressed in exploring the use of SIP Events  
outside the realm of real-time communications. Henning has created a  
list on which to start those discussions.

* The new mechanism suggestions in the Interdomain Optimization  
Analysis draft will be removed to a separate document. The group will  
focus on reviewing the model and analysis in the document with the  
expectation that we will last call and request publication of this  
draft achieving the associated milestone item before the Chicago  
meeting.

* The attendees reconfirmed accepting neimi-chat as the basis for  
meeting our IM chat milestone. Conversation indicated we are making  
progress on providing an immediate solution that will be compatible  
with the long term XCON solution

* There was significant pushback against optimizing MSRP by dropping  
To-path and From-path in Aki's MSRP-ice proposal. There was interest  
in continuing to discuss the remainder of the document.

Raw Notes
----------------------------------

Topic: Status
lead: Robert Sparks
Slides presented

Issue: Advanced Messaging Draft:

Should we revive or let expire? Discussion indicated might depend on  
following conversation.

Issue: OMA LS on XCAP DIFF:

Meeting held yesterday.

We understand issues and are working on it.

Issue: Remaining Milestones

IMDN submission should occur soon.

Adam Roach will edit SIMPLE Protocol Annotated Review for Chicago

Question: If SIMPLE concludes this year, where would further work go?  
Answer: to RAI  ADs or individuals as appropriate.

Issue: IMDN

Bug found in extension of cpim namespace. Corrective changes made and  
under review. Will submit to IESG LC if review OK.

Topic: DMDN
lead: Jerry Shih
Slides presented

OMA SIMPLE IM is based on IETF SIMPLE IM. Presentation overviewed  
messaging model.

Questions on Read notification for Large Message Mode slide:

Henry: If we don't get an error message, we presume it has been  
delivered, and if we did get a notification we would be aggravated.  
Also people often delete messages without reading them. How do you  
define "being read"?

Answer: Delivery notification is optional and used only if desired,  
so won't annoy people who don't use it. Determining if a message has  
been read is implementation dependent.  The implication is that the  
message has been rendered to a user interface and acted on by a user.

Discussion followed broadly. Concerns about regulatory implications  
were raised. Noted that IMDN has a comparable capability. Further  
discussion deferred by order of the chair.

Questions on slide Delivery Notification for Session based Deferred  
Messaging

Ben Campbell noted that he resisted IMDN in MSRP, because we had no  
explored the use cases enough to understand how it needs to work. For  
example, the current slides talk about delivery after an MSRP session  
ends, which requires deliver on an alternate path and is forbidden  
explicitly in the current spec. It would be good to have a broader  
set of use cases to make sure we get this right.

Miguel Garcia noted that there is value in delivery notification and/ 
or read notification and it should be explored, but that the use case  
requires clarification on when it is needed. It needs to be more  
session based.

Noted there is a spam harvesting risk that might need to be addressed  
(although 200 OK may have leaked that same information).

Q: do we have delayed notification, and is declining a message a UI  
issue? ANs: Not yet, and yes.

Proposed by Dean Willis that that the OMA messaging protocol provides  
a session layer mechanism that spans multiple IETF protocols, and it  
is probably required that the OMA delivery notification mechanism  
operate at that same level. IETF protocols might each require a  
delivery notification capability, but the aggregation of this into  
the OMA "read" condition has to happen at an OMA layer.

Topic: Presence Specific Dictionary for SIGCOMP
lead: Miguel Angel Garcia-Martin
Slides presented

Document "mostly ready" to ship. Recently received input to remove  
small (less than 4 char) entries from dictionary.

Help is needed in reviewing, specifically around  
"priorities" (probably of use) classification for strings. This might  
require analyzing a large body of messages in different languages and  
dialects for best fit, but analysis for distribution in things like  
PIDF might also be very useful.

Poll: Who will give feedback on this draft: 5 hands presented.

Question to AD: Can this progress without a WG or should it go  
through here? Ans: (JonP) If you can find reviewers, AD will take as  
AD-sponsored individual

Topic: Vehicle Event Package
lead: Henning Schulzrinne
Slides presented

Noted that US government application CAP uses XMPP for somehing very  
similar, but needs to be broadened.

Issue: Previously, asynchronous events outside of presence and MWI  
have been considered out of scope.

Options: 1) Not at all in IETF, 2) Use XMPP, 3) make a per-case  
decision by expertise, size, etc. 4) build a general-purpose asynch  
event mechanism using SIMPLE as a basis

Discussion: There are a lot of examples of information sources like  
this in Public Safety arena, where much work has been done on  
formatting the messages but not on transporting them.

Brian Rosen expressed strong interest in the work.

Question: Why here and not SIPPING? And: SIPPING was too busy this week.

Question (Adam Roach) We originally had explicit instruction from  
IESG about not doing a general subscription notification message  
system like TIBCO. Will we be receiving guidance from the IESG that  
the language in 3265 no longer applies, or does the guidance stand.  
Noted that the same concerns would apply to XMPP and the rest of RAI.

Noted by Miguel Garcia that there are concepts in the drafts he is  
scheduled to present in SIPPING tomorrow that relate to this work.

Avshalom Houri expressed interest in the work. Not sure where it  
should be done.

Henning noted that the whole set of things we've built, including  
partials, diffs, filtering, etc are perfectly applicable.

Issue: Group Management. Miguel's work includes concept of  
"Communities" that are similar and should be coordinated.

AD Guidance: Original guidance is that SIMPLE is in support of human  
real-time communications. Noted also that event packages are  
"informational required" and do not have to be done only in SIMPLE/ 
SIPPING.

Poll: Interest level in room is relatively high.

Topic: SIMPLE Problem Statement
lead: Avshalom Houri
Slides presented

Intro by chair: Not certain that current draft universally hits the  
main point for the analysis required in the charter. We will need to  
make some decisions about how to arrange this.

Note: "Numbers" slide, 5th column is messages per 8 hour day

Discussion from Brian Rosen: Agreed that this shows a problem, but it  
would be useful to get a better handle on the size of the problem.  
This isn't protocol specific, it's presence-specific.

Discussion from HGS: There were some papers about AT&T's network that  
we might could extract useful data from. But it is hard to put an  
upper limit on a scary number.

Guidance from chair: This draft is now at the point where its model  
could be usefully compared to real experience. Please do so.

Request from Ben Campbell: Would like to see feedback on his analysis  
as posted.

Question from Henry Sinnreich: If you think this is the usage  
scenario, is this an argument that these big-load applications (like  
presence) should be handled in the endpoints and not the servers?  
Ans: maybe . . .

Issue: Optimizations

Comment from HGS: Google seems to be doing something like that  
already. The goal is reducing load, not shifting it around.

Comment from Adam Roach: There are two sets of stuff here 1) existing  
mechanisms 2) new mechanisms for which we have not yet done an  
adequate requirements analysis. The document can be split along these  
lines. Adam would support the further optimization work.

Comment from HGS: Could also have an informational on "lazy"  
approaches that can be implemented in today's protocols without change.

Comment from Sriram: Young users often use their presence status to  
communicate like a broadcast message, perhaps 3-4 times per minute.  
This isn't true of enterprise users,  the distribution could be very  
large.

Topic: SIMPLE Chat draft
lead: Miguel Angel Garcia-Martin
Slides presented

Issue: nicknames.

Discussion: In other sessions, nicknames are a property of the use,  
not a property of the chat. Do we need to sove this or the general  
prolem?

Adam noted that everything we do here will apply to xcon. Aki will  
look through xcon data model for a way to do it, and we'll have a  
system-wide capability.

Ben noted that we have to be careful, because once the approach is in  
code, the feature requirement will be there forever. That will make  
it hard to change over.

Mary asks that we make sure what we do here is NOT the general model  
for xcon.

Adam confirms that these features will hag around, but that would not  
be as bad as not having the capabilities now. in his opinion the  
amount of work involved is relatively small.

Question from Ben: Does the draft contain motivation for doing this  
in media stream instead of in SIP

TO DO: Find this motivation and put it in draft.

Comment from ben: Doing it this way will require ability to provision  
both focus and mixer with  nickname.

Comment from Brian Rosen: Ben's comment makes sense. Don't remember  
any discussion of this in the past. We should make this nicknaming  
SIP-wide.

Comment from Adam: XCON does operations towards the focus, not the  
mixer, so may need to look at this.

Comment from Aki: We previously said that if we put this stuff in the  
SDP then we're negotiating both session and nickname. This requires  
new response codes for "nickname taken". Also not pretty to have to  
use a reinvite to change nicknames mid-chat.

Issue: Will you work on this?

Comment from Brian Rosen: Yes.

Comment from Ben:  Yes, and we need to analyze impact on end-to-end  
encryption.

Comment from Henry: We must do this to be able to use SIMPLE instead  
of XMPP. But we need to think about how this works in a serverless  
environment.

Comment from Brian: End-system (multicast, broadcast, many-cast)  
mixing can meet the serverless.

Poll from chair: Do we still have consensus to keep this as a basis  
for a WG item to meet our charter? Ans: We have consensus on doing  
this work.

Topic: XCON work on MSRP conferencing
lead: Mary Barnes
Slides presented

No discussion from room.

Topic: MSRP ICE
lead: Aki Niemi
Slides presented

Intended as a replacement for MSRP relays. Current draft is a  
strawman intended to get discussion going.

Issue; Dropping To-Path, From-Path

Comment from Ben campbell. Would be a chore to change MSRP just to do  
the discard of To-path and From-Path as suggested. Would also like to  
see case where one end uses relay, one end uses ICE.

Comment from Adam. Dropping them is much like dropping tags in SIP  
and breaking forking.

Comment from Robert Sparks

Comment from Hadriel Kaplan: This is probably too much of a change

This raises the question: if you keep them, what do you put there?

Issue: RFC 4571 framing. Why are we doing this in ice-tcp?

Comment from Adam Roach: We probably need to do something different  
from 4571 because it has a length header and this messes up arbitrary  
chunking. We probably need to come up with yet another mechanism.

Comment from Henry: This draft is very useful because it moves more  
things to the endpoints. We should do it.

 From chair: If you want to work on this: DO SO!

Meeting closed.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple