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
|
