[Notifications] Draft Minutes from IETF 69 meeting

[Cullen Jennings <[e-mail]>]

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