Draft Minutes from IETF 69 meeting
Cullen Jennings <fluffy <at> cisco.com>
2007-07-27 22:19:28 GMT
Some draft minutes - thank you Dean for the notes.
Please reply with text to fix any important mistakes, omissions, etc.
before Aug 17.
Thanks, Cullen
------------------------------------------------------------------------
--------------
Friday July 27, 2007
Palmer Hilton, Chicago
Salon 2
Meeting chaired by Cullen Jennings, Randall Gellens
Audio recording at
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch7-
fri-am.mp3
Attendance: roughly 30 people
The key next steps is to bring together a set of use case. We would
like the use cases to be separated in to priority 1 use cases that
needed to be solved in the initial work a proposed WG, and priority
2 use cases that could be left to a second phase. The goal is to only
have things in priority 1 where the contributor of the use case felt
they the use case was absolutely critical and there was no way they
could live without the use case in the first phase.
These use case would be used to derive some requirements and
determine if there are a bunch of common requirements that all the
participants can work on or if there are N people with N different
requirements. The requirements would then be used to check that
Lisa's straw man architecture looked like a plausible way to meet the
identified requirements.
Lisa Dusseault, Scott Lawrence, Dave Crocker, Alexey Melnikov, Philip
Guenhter, Robert Sparks, and Zoltan Ordogh agreed to provide text for
use cases. Philip volunteered to collate them into a draft. Pete
Resnick offered to provide wine to the folks providing use cases.
From this point, Chris Newman would like to see us develop a draft
charter then propose a WG forming BOF. Input documents would include:
draft charter, use cases and start of requirements, start of
architecture / model draft.
----- RAW NOTES
------------------------------------------------------------
Reported by Dean Willis
Topic: Status and Agenda Bash
Agenda accepted as presented.
Cullen described the basic problem of the group as asynchronous
notification about interesting things occurring at mail stores.
Chris Newman reviewed the longstanding position of not entering this
arena in the IETF. However, more recent developments in asynchronous
notification services around SIP and JABBER/XMPP have made it appear
more feasible.
Andrew Allen asked if this work is scoped to SIP or other protocols
like XMPP or anything else in CPP.
Term "CPP" (Common Profile for Presence) clarified, as things like
SIP events aren't necessarily CPP, even though the SIP events could
ship presence. CPP isn't really the right term, but is used here as a
placeholder.
Topic: Analogy to CPP
led by Lisa Dusseault
Slides presented
Noted that the filter layer would benefit from not having to do much
in the way of email handling.
Noted that the feature discovery mechanisms of SIP and XMPP could be
used for tuning filters.
Questions . . . .
Pete Resnick shares discomfort with calling the notification
aggregator an "hourglass". Both the email server and the client have
lightweight connections. So what's the limiting factor here to keep
the ends of the pipe tiny?
Lisa believes the descriptive factor for the server interface is that
the information sent should be reasonable for an email server to send
on very message.
An unstated goal is to extend this sort of architecture to other
systems, such as databases.
Question (Avshalom Houri): Is the scope of this group email only?
Response from AD and Lisa: That remains to be determined. But the
intent is to have a very simple initial design for email, knowing
that it may be extended later.
From Harald: The draft uses the word "folder" without defining it
This may be too narrow.
From Harald: The "narrow place in the architecture" might be called
an "interface".
Randy G suggests further that we concentrate on minimal state needed
for email.
Philip Noted that we have an interest in reusing the existing
subscription channels of cell phones instead of holding a full imap
connection all the time. There is an interesting use case when a
client has lost connectivity and regains it. If the client is already
going to connect to its notification service anyhow, the overhead of
also connecting to the mail store to check for messages could be
avoided.
Tony Hansen raised question on time filtering, such as "If a mail
from my boss comes in between nine and five, forward an extract to my
cell phone".
Suggested that we look at reliable notification on a larger scale.
AD noted that this work item could be on the lemonade charter. Why
isn't it? AD hopes it will be a template for other applications. But
making things "generic" usually results in unachievable goals. This
should be extensible, which is much easier to meet.
Randall noted that we should keep it very simple, otherwise fast
resync using IMAP might as well be used.
Aki suggests that there is no real advantage to using UDP for
notification, and that mobiles are actually better off using TCP.
Debate continued on relationship to IM system.
Noted that the architecture slide says "mail store", not "imap store".
Noted by Zoltan that it has hard to bottle up the "state" of an email
store, and easier to communicate a state change on that store.
Including specifics of the data raises security issues.
Dave Crocker suggests that documenting concrete scenarios as a first
activity, along with constraints we believe those scenarios raise
would help.
Question: Do we have requirements for content protection and signing
of notifications? Chris Newman holds this to be out of scope.
Topic: Charter
Led by Cullen Jennings
Slides presented
In addition to an architecture, a blast protocol, a schema, and a CPP
binding, what should we produce? Crocker suggested scenarios.
Discussion centered on difference between message-specific state and
mail-store state, and which should be included in either blast or
notification protocols.
Noted that there are other things about messages, like size,
encoding, etc.
Rohan says he is confused as to whether the goal is the limited
lemonade message data or something more elaborate.
Harald thinks we are confusing requirements on blast with requirement
on cpp. Blast should carry info about the cause of the event. Not so
sure about CPP. Suggests also that client might be shielded from
notification about statechanges caused by clients.
Scott lawrence counters that users DO want immediate notification on
states they change.
Proposed that the BLAST protocol could be met by IMAP with subscribe.
Rohan wonders if there is a watched-feature negotiation feature
needed on the blast protocol.
Chris Newman reminds us that the goal is to have a more generic-than-
lemonade protocol on BLAST.
Harald wonders why the blast protocol sends everything instead of
filtering it, noting that this indicates that filtering should also
be in the notification service and not in the client.
Aki explains that the state controlling the "you have mail" indicator
is not whether you have unread messages, but if you have unread
messages that have been received since the last time the mailbox was
visited.
Lisa suggests that we could do things like switch from "message
received" to "message received" and back again.
Dave Crocker suggests we strive for a common subset that we clearly
understand what they do.
Cullen notes that a use-case document should be an early deliverable.
Randall hopes we are NOT including MWI in the first release. Perhaps
a "Something has changed and you should resynch.
Zoltan asks if this connection is to be used with or without a
concurrent IMAP connection?
Discussion indicates that there are devices that are not IMAP clients
but would like to indicate status of a mail store.
Aki noted that not all email stores are imap.
Dave Crocker suggests that the notification service should be very
lean with no understanding of what is being sent.
Zoltan asks "If you don't use IMAP, how do you activate the red light
to start with?" The answer is "use a CPP subscribe mechanism".
Lisa noted that it is important to not filter in the mail store in
order to optimize performance.
Pete Resnick refutes this, saying the message processing load on the
notification service makes it need to know as much as an IMAP client
would. Lisa argues that this could be at the CPP server.
At heart, the concern is about what specific events are getting
reported on BLAST, If everything that happens is reported, then
somebody has to knot it back together. If only summary-level events
are reported, then upstream becomes much easier.
Cullen proposes that we work backward from use case to fan-out to
notification service to blast protocol to mail store.
Adam restates this as "BLAST must send not just events, but
consequent states."
Scott Lawrence emphasize that intelligence about data has to live
were that data lives.
Randall reminds us that goal was to reduce complexity on mail server,
so it (BLAST) does only minimal sending of raw data -- events and
current states. The notification service then determines who this
goes to.
Lisa reminds us that this architecture is based from buddy lists, and
we have a hard time predicting now how many people might subscribe to
state changes on a popular public mailbox or atom feed. But it all
comes back to the use cases . . . .
Chris reminds is that the mail store knows the mail store state and
changes. The CPP instead is good at managing subscriptions and
publications. This architectural distinction is good and necessary.
Randall notes that instead of coming up with use cases, we need to
narrow our scope of use cases to the minimal reasonable set.
Dave Crocker suggests that what is missing from the diagram is a line
between the mail store and the clients. This is apparently in the
doc, not in the slides.
Aki thinks that a major benefit of the blast protocol is the
delegation for access to the state information from the mail store to
the notification service. The access being delegated here is far more
restricted than that which would be provided by full IMAP.
Topic: What are Next Steps
Pete worries that there may be thirty different use cases (in the
room) based on the idea that BLAST does just exactly what they think
it does. We have a big mismatch on the expectations and need to come
to closer agreement here before.
Agreed that we should settle on a narrow set of starter use cases.
We also need to look at the authentication and delegation issues.
Poll: Who would be willing to work on use cases: Lisa, Scott
Lawrence, Dave Crocker, Alexey, Philip, Robert Sparks, Zoltan. Pete
agrees to whine about other people's use cases. Philip volunteered to
collate.
People should also try to prioritize their use cases into "Phase 1,
phase 2, phase 3".
The mailing list "notifications <at> ietf.org" will be used for further
work by this group.
RSS Feed