Subject: [lemonade] Notes from the Jan 25th jabber chat on notifications

From: "Glenn Parsons" <[email-masked]>
Date: Fri, 23 Feb 2007 17:26:44 -0500

LEMONADE Notifications chat
January 25, 2007
=======================================================

Full log:
http://www.ietf.org/meetings/ietf-logs/lemonade/2007-01-25.html

Online personalities:
		bernard.desruisseaux 
		eburger - Eric Burger
		alexeymelnikov
		Glenn Parsons
		Dave Cridland
		Ams -  Abhijit Menon-Sen
		Lisa - Lisa Dusseault
		Arnt - Arnt Gulbrandsen
		Rohan - Rohan Mahy

Discussion
-------------

Current documents:
		draft-newman-lemonade-msgevent-00
		draft-ietf-lemonade-notifications-03
		OMA MEM REQ & AD
		draft-mahy-sieve-notify-sip-00

Types of notifications
*	out of band
*	real time
*	various transport mechanisms - SIEVE, IMAP events, ...

Types of out of band notifications
*	new message notification
*	new message notification with different degrees of details
*	mailbox state change notification
*	file updated

Things to decide about notifications:
*	how to send 
*	who to send to
*	what to send

Concern about clients avoiding sync really being a subvertive IMAPv5

Concern on frequency of SIEVE messages for notifications has been
alleviated, however there is still an issue on how to deal with multiple
devices.

SIEVE scripts (for mobile devices) will tend to be semi-permanent, there
was a concern noted that designing for this might prohibit dynamic
scripts.  SIEVE is obvious for 'user oriented' notifications, but it is
overkill for MWI.  MWI is already defined using SIP (RFC 3842) but is
that necessary for email?

Notifications are best-effort.  And account related notifications are
also out of scope.
 
Consensus:  We are only talking about email-related notifications, not
calendar notifications, and these can be sent with a number of
protocols.  

Structured notifications or free text?

Use cases?

Security needed for notifications

Focus on MWI first (e.g., using IMAP IDLE), leave the user details to
SIEVE draft.  That is no subject or other data.  However, the SIP MWI
already does this - counts are reliable, the other data is not.   

Consensus:  Reuse RFC 3842 - or an XMPP clone of it if necessary, unless
a good argument is made to the contrary.

Summary:
1.	notifications scope is e-mail
2.	follow _model_ of RFC 3842
3.	figure out transport later
...
4.	find a 6 year old editor...

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade