Re: [Notifications] Draft Minutes from IETF 69 meeting

[Eric Burger <[e-mail]>]

Let us not forget someone coming to the mike and essentially saying, "Please
do not screw up lemonade."


On 7/27/07 5:19 PM, "Cullen Jennings" <[e-mail]> wrote:

> 
> 
> 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 "[e-mail]" will be used for further
> work by this group.
> 
> 
> _______________________________________________
> Notifications mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/notifications
> 



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.


_______________________________________________
Notifications mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/notifications