From notifications-bounces@ietf.org Tue Jan 02 14:02:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1oth-0002dW-BV; Tue, 02 Jan 2007 14:02:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1otf-0002bL-SZ for notifications@ietf.org; Tue, 02 Jan 2007 14:02:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ote-00037Y-Af for notifications@ietf.org; Tue, 02 Jan 2007 14:02:03 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l02J1ri9030933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Jan 2007 11:01:53 -0800 Received: from [[192.168.1.13]] (vpn-10-50-16-31.qualcomm.com [10.50.16.31]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l02J1pti007427; Tue, 2 Jan 2007 11:01:52 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 2 Jan 2007 10:56:20 -0800 To: Eric Burger , "notifications@ietf.org" From: Randall Gellens Subject: Re: [Notifications] Notifications Types for Lemonade Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org I can't make 1/24 nor 1/25. How about 1/22 at 5:00 PM EST, or 1/23 at noon EST? At 10:30 AM -0500 12/28/06, Eric Burger wrote: > Drawing on Dave's e-mail: > > Do we have any interest in notifications OTHER than: > > MWI (Message Waiting Indicator) - "You have 2 new messages, 1 fax message, > and 99 old messages" Is the purpose of this solely to enable a device to turn on or off enunciators (e.g., voice mail or email icon on main phone screen)? More specifically, is the intent that this is primarily intended as input to a device's main UI, as opposed to a specific application on a device (such as an email client)? > OOB Sync Messages (Out-of-Band, i.e., not IMAP) - "Hey - wake up! You have > some work to do at the server." Is the purpose of this intended to be limited to such wake-ups? If the intent is to exclude more detailed information (such as the sender address, subject text, attachment and size information) then we have a very simple protocol with limited security needs. Such a protocol can probably be mandatory to implement, but provides only a subset of the desired cool capabilities. (This is often a good thing to start with.) > User-Directed Alerts - "That important message from your boss just arrived." The differences between each of the three categories involve the level of detail supplied (and hence the security requirements), complexity, and user control. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The peace we seek, founded upon decent trust and cooperative effort among nations, can be fortified, not by weapons of war but by wheat and by cotton, by milk and by wool, by meat and by timber and by rice. These are words that translate into every language on earth. These are needs that challenge this world in arms. This Government is ready to ask its people to join with all nations in devoting a substantial percentage of the savings achieved by disarmament to a fund for world aid and reconstruction. The purposes of this great work would be to help other peoples to develop the underdeveloped areas of the world, to stimulate profitability and fair world trade, to assist all peoples to know the blessings of productive freedom....The monuments to this new kind of war would be these: roads and schools, hospitals and homes, food and health.... We are ready, in short, to dedicate our strength to serving the needs, rather than the fears, of the world. --U.S. President Dwight D. Eisenhower, April 16,1953 _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jan 02 14:02:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ouS-0003DU-58; Tue, 02 Jan 2007 14:02:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1ouR-0003DN-3x for notifications@ietf.org; Tue, 02 Jan 2007 14:02:51 -0500 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H1ouO-0003HE-JG for notifications@ietf.org; Tue, 02 Jan 2007 14:02:51 -0500 Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l02J2i7n002769 for ; Tue, 2 Jan 2007 11:02:44 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JB9006018V5JF00@d1-sfbay-10.sun.com> (original mail from Anil.Srivastava@Sun.COM) for notifications@ietf.org; Tue, 02 Jan 2007 11:02:44 -0800 (PST) Received: from [192.18.187.64] (host-64-187-18-192.iplanet.com [192.18.187.64]) by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JB9007418WJK420@d1-sfbay-10.sun.com> for notifications@ietf.org; Tue, 02 Jan 2007 11:02:43 -0800 (PST) Date: Tue, 02 Jan 2007 11:02:40 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: [Notifications] Notifications Jabber Chat In-reply-to: To: notifications@ietf.org Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Communication Suite 5 References: X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org [X] January 24, 10am Eastern Time [X] January 25, 10am Eastern Time On 2006-12-27/16:23 [-0500], eburger@cantata.com [Eric Burger] wrote: > We would like to have a Jabber Chat to discuss notifications, with a focus > on Lemonade, but open to the larger problem space. > > We would propose the following dates. Please respond to the NOTIFICATIONS > list , not the LEMONADE list > . > > [X] January 24, 10am Eastern Time > [X] January 25, 10am Eastern Time > [ ] Other: _______ > > Thanks. > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications > _______________ Anil SRIVASTAVA | anil.srivastava@Sun.COM | Sun Microsystems, Inc _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Jan 03 09:28:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H276Y-0007pi-1V; Wed, 03 Jan 2007 09:28:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H276W-0007pd-QR for notifications@ietf.org; Wed, 03 Jan 2007 09:28:32 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H276V-0001ch-G8 for notifications@ietf.org; Wed, 03 Jan 2007 09:28:32 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1H276R-0007Sw-Qz; Wed, 03 Jan 2007 14:28:27 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id ED157498003; Wed, 3 Jan 2007 14:28:29 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21435-08; Wed, 3 Jan 2007 14:28:21 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 6B1FE498005; Wed, 3 Jan 2007 14:28:21 +0000 (GMT) Date: Wed, 03 Jan 2007 14:28:18 +0000 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <6991.1167834499.104216@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Message Notifications interest group discussion list Subject: [Notifications] Jabber chat times. X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Tue Jan 2 18:56:20 2007, Randall Gellens wrote: > I can't make 1/24 nor 1/25. > > How about 1/22 at 5:00 PM EST, or 1/23 at noon EST? > > 5pm EST is 22:00 for me in UTC, and 23:00 for most of Europe. I can do this, but I'm not sure you'd get useful input. Noon is 5pm for UTC, 6pm for CET. I can do this. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Jan 03 12:00:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Tz-0001os-4w; Wed, 03 Jan 2007 12:00:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29Ty-0001oJ-JU for notifications@ietf.org; Wed, 03 Jan 2007 12:00:54 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29Tx-0007sY-5E for notifications@ietf.org; Wed, 03 Jan 2007 12:00:54 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.50) id 1H29Tr-0004PX-OH; Wed, 03 Jan 2007 17:00:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id ECCB7498003; Wed, 3 Jan 2007 17:00:50 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23560-03; Wed, 3 Jan 2007 17:00:43 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 2264E498005; Wed, 3 Jan 2007 17:00:43 +0000 (GMT) Date: Wed, 03 Jan 2007 17:00:39 +0000 Subject: Re: [Notifications] Notifications Types for Lemonade References: In-Reply-To: MIME-Version: 1.0 Message-Id: <6991.1167843639.751581@peirce.dave.cridland.net> From: Dave Cridland To: Randall Gellens Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Message Notifications interest group discussion list X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Tue Jan 2 18:56:20 2007, Randall Gellens wrote: >> MWI (Message Waiting Indicator) - "You have 2 new messages, 1 fax >> message, >> and 99 old messages" > > Is the purpose of this solely to enable a device to turn on or off > enunciators (e.g., voice mail or email icon on main phone screen)? > More specifically, is the intent that this is primarily intended as > input to a device's main UI, as opposed to a specific application > on a device (such as an email client)? > > Good question - I've heard this discussed as part of the notification area of Lemonade, and I'd got it into my head that we were talking about a simple icon or blinking light - very much a boolean indicator, rather than a numeric display. >> OOB Sync Messages (Out-of-Band, i.e., not IMAP) - "Hey - wake up! >> You have >> some work to do at the server." > > Is the purpose of this intended to be limited to such wake-ups? If > the intent is to exclude more detailed information (such as the > sender address, subject text, attachment and size information) then > we have a very simple protocol with limited security needs. Such a > protocol can probably be mandatory to implement, but provides only > a subset of the desired cool capabilities. (This is often a good > thing to start with.) > > Well, I'd really seen this as a protocol to avoid synchronizing - what various people have described as "true push". A "sync needed" protocol is really a lot simpler, and simple STATUS message packaging probably do for that and the MWI scenario very nicely. I'd also state for the record that I don't think we need more than a STATUS response, but pushing content and detailed state out of band has been a consistent feature of many proposals. >> User-Directed Alerts - "That important message from your boss >> just arrived." > > The differences between each of the three categories involve the > level of detail supplied (and hence the security requirements), > complexity, and user control. I'm not so sure. I think the first two can be seen as the limits on a spectrum of machine-readable notifications, whereas machine readability isn't nearly so important when considering a user-directed alert. Luckily, I also happen to think that user-alerts are essentially taken care of by Sieve, on delivery. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Jan 03 12:23:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29pR-0006V6-A4; Wed, 03 Jan 2007 12:23:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H29pQ-0006Ul-0o for notifications@ietf.org; Wed, 03 Jan 2007 12:23:04 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H29pO-0003g8-15 for notifications@ietf.org; Wed, 03 Jan 2007 12:23:03 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7EB74142257; Wed, 3 Jan 2007 09:22:59 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08259-03; Wed, 3 Jan 2007 09:22:59 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 806C5142256; Wed, 3 Jan 2007 09:22:58 -0800 (PST) In-Reply-To: <6991.1167843639.751581@peirce.dave.cridland.net> References: <6991.1167843639.751581@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CD30338-ABA4-4B5B-95EE-ACE923B6E007@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Notifications] Notifications Types for Lemonade Date: Wed, 3 Jan 2007 09:22:55 -0800 To: Dave Cridland X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Message Notifications interest group discussion list X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org On Jan 3, 2007, at 9:00 AM, Dave Cridland wrote: > On Tue Jan 2 18:56:20 2007, Randall Gellens wrote: >>> MWI (Message Waiting Indicator) - "You have 2 new messages, 1 >>> fax message, >>> and 99 old messages" >> Is the purpose of this solely to enable a device to turn on or off >> enunciators (e.g., voice mail or email icon on main phone screen)? >> More specifically, is the intent that this is primarily intended >> as input to a device's main UI, as opposed to a specific >> application on a device (such as an email client)? > Good question - I've heard this discussed as part of the > notification area of Lemonade, and I'd got it into my head that we > were talking about a simple icon or blinking light - very much a > boolean indicator, rather than a numeric display. I use "Google Notifier" (which uses pull, not push notifications but we can take it as a real-life use case) to let me know when to check mail hosted by google. - It displays a coloured icon and a number when I have unread messages (number of unread msgs) - It displays the sender and the first 20 or so characters of the last four unread messages. - It displays how fresh the information is ("Checked 1 min ago") Another use case is a calendar client that can be configured to look at your IMAP Inbox directly, and it wants to get notified when there are incoming iMIP messages rather than poll frequently (I guess the message ID would be nice to allow it to quickly download the whole message). > > >>> OOB Sync Messages (Out-of-Band, i.e., not IMAP) - "Hey - wake >>> up! You have >>> some work to do at the server." >> Is the purpose of this intended to be limited to such wake-ups? >> If the intent is to exclude more detailed information (such as the >> sender address, subject text, attachment and size information) >> then we have a very simple protocol with limited security needs. >> Such a protocol can probably be mandatory to implement, but >> provides only a subset of the desired cool capabilities. (This is >> often a good thing to start with.) > Well, I'd really seen this as a protocol to avoid synchronizing - > what various people have described as "true push". A "sync needed" > protocol is really a lot simpler, and simple STATUS message > packaging probably do for that and the MWI scenario very nicely. My opinion is that it would be good to get notifications working at all, before trying to build true-push synchronization. I'd prefer to have synchronization be out-of-scope for notification work. Lisa _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Wed Jan 03 18:24:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FT2-0005X4-Fz; Wed, 03 Jan 2007 18:24:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2FT1-0005VP-HP for notifications@ietf.org; Wed, 03 Jan 2007 18:24:19 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2FT0-0004u3-4U for notifications@ietf.org; Wed, 03 Jan 2007 18:24:19 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l03NOER1002271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Jan 2007 15:24:15 -0800 Received: from [loud.qualcomm.com] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l03NODKp003706; Wed, 3 Jan 2007 15:24:14 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <6991.1167843639.751581@peirce.dave.cridland.net> References: <6991.1167843639.751581@peirce.dave.cridland.net> X-Mailer: Eudora for Mac OS X X-message-flag: Warning: Outlook in use. Upgrade to Eudora: Date: Wed, 3 Jan 2007 15:24:10 -0800 To: Dave Cridland , Randall Gellens From: Randall Gellens Subject: Re: [Notifications] Notifications Types for Lemonade Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Message Notifications interest group discussion list X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org At 5:00 PM +0000 1/3/07, Dave Cridland wrote: > On Tue Jan 2 18:56:20 2007, Randall Gellens wrote: >>> MWI (Message Waiting Indicator) - "You have 2 new messages, 1 fax message, >>> and 99 old messages" >> >> Is the purpose of this solely to enable a device to turn on or off >> enunciators (e.g., voice mail or email icon on main phone screen)? >> More specifically, is the intent that this is primarily intended >> as input to a device's main UI, as opposed to a specific >> application on a device (such as an email client)? >> > Good question - I've heard this discussed as part of the > notification area of Lemonade, and I'd got it into my head that we > were talking about a simple icon or blinking light - very much a > boolean indicator, rather than a numeric display. > >>> OOB Sync Messages (Out-of-Band, i.e., not IMAP) - "Hey - wake >>> up! You have >>> some work to do at the server." >> >> Is the purpose of this intended to be limited to such wake-ups? >> If the intent is to exclude more detailed information (such as the >> sender address, subject text, attachment and size information) >> then we have a very simple protocol with limited security needs. >> Such a protocol can probably be mandatory to implement, but >> provides only a subset of the desired cool capabilities. (This is >> often a good thing to start with.) >> > Well, I'd really seen this as a protocol to avoid synchronizing - > what various people have described as "true push". A "sync needed" > protocol is really a lot simpler, and simple STATUS message > packaging probably do for that and the MWI scenario very nicely. > > I'd also state for the record that I don't think we need more than > a STATUS response, but pushing content and detailed state out of > band has been a consistent feature of many proposals. > >>> User-Directed Alerts - "That important message from your boss >>> just arrived." >> >> The differences between each of the three categories involve the >> level of detail supplied (and hence the security requirements), >> complexity, and user control. > > I'm not so sure. I think the first two can be seen as the limits on > a spectrum of machine-readable notifications, whereas machine > readability isn't nearly so important when considering a > user-directed alert. Interesting -- I hadn't thought about machine readability as an aspect of this -- I'd been assuming that all notifications were machine-readable and would be interpreted by the client or device, and then acted on in some way (ignore, silently update cache, defer, download in background, display something to user, etc.) So I was thinking of user-directed as user-specified criteria, that is, the "directed" meaning "directed by" instead of "directed at" (the user). For notifications directed at the user and not intended for processing by the device or client, does lemonade need to be involved at all? > Luckily, I also happen to think that user-alerts are essentially > taken care of by Sieve, on delivery. For user-readable alerts, I'd agree. For machine-readable, I'd want to be sure it is covered properly. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- You may be only one person in the world, but you may also be the world to one person. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jan 08 20:49:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H467a-0003Qj-Ij; Mon, 08 Jan 2007 20:49:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H467Z-0003Qb-3I for notifications@ietf.org; Mon, 08 Jan 2007 20:49:49 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H467X-0006pc-QO for notifications@ietf.org; Mon, 08 Jan 2007 20:49:49 -0500 Received: by ug-out-1314.google.com with SMTP id 72so6039037ugd for ; Mon, 08 Jan 2007 17:49:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=O4aX6iMfsCyUWgpoUNOrK1qttOCkoS0ogvb2E2rxlzjyNhGKTiNMTPdkjX1YrrHm7Vr4coytmeXzLQFCPw/b28Oei5e6HK91f/GgTTqA3mdWP4LlCvQ5TLbzqPY7h+onG3YmIjEvslFN99VIpUZzG3OJ2I6oZADVz/fPmpLXIB4= Received: by 10.78.185.7 with SMTP id i7mr4341443huf.1168307386757; Mon, 08 Jan 2007 17:49:46 -0800 (PST) Received: by 10.78.151.2 with HTTP; Mon, 8 Jan 2007 17:49:46 -0800 (PST) Message-ID: <953beacc0701081749n46286f41ic500ebf96d33ee9d@mail.gmail.com> Date: Mon, 8 Jan 2007 17:49:46 -0800 From: "Rohan Mahy" To: notifications@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Rohan Mahy Subject: [Notifications] draft on using SIP for email notifications X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Hi, I wrote a draft describing how to extend the message-summary event package (currently used for MWI) to do sieve notifications. Until it appears in the archive, it is here: http://svn.resiprocate.org/rep/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.html http://svn.resiprocate.org/rep/ietf-drafts/rohan/email-event/draft-mahy-sieve-notify-sip-00.txt btw: I do not have a real stake in this discussion. As author of some related technology I thought I would enumerate one way to do it. thanks, -rohan _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jan 09 21:54:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4TbB-0000Mi-HS; Tue, 09 Jan 2007 21:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4EBH-0000Pe-AC for notifications@ietf.org; Tue, 09 Jan 2007 05:26:11 -0500 Received: from moutng.kundenserver.de ([212.227.126.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4EBC-0007vf-Sp for notifications@ietf.org; Tue, 09 Jan 2007 05:26:11 -0500 Received: from [84.160.198.103] (helo=noname) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1H4EBB1AIR-0000MD; Tue, 09 Jan 2007 11:26:06 +0100 From: Martin Konold Organization: erfrakon To: notifications@ietf.org Date: Tue, 9 Jan 2007 11:27:45 +0100 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701091127.45392.martin.konold@erfrakon.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b04c3ed30b43fd5a3d557b6dbc75a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Tue, 09 Jan 2007 21:53:56 -0500 Subject: [Notifications] Re: [lemonade] Notifications Jabber Chat X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Am Mittwoch, 27. Dezember 2006 22:23 schrieb Eric Burger: > [ ] January 24, 10am Eastern Time not possible for me (travelling) > [ ] January 25, 10am Eastern Time Fine > [ ] Other: _______ Any later date like January 30th. 13am Eastern Time Regards, -- martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Stuttgart - Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/ _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jan 15 18:16:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6b3s-0006FL-AH; Mon, 15 Jan 2007 18:16:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6b3q-0006FF-VM for notifications@ietf.org; Mon, 15 Jan 2007 18:16:18 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6b3n-0004hu-T2 for notifications@ietf.org; Mon, 15 Jan 2007 18:16:18 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 739DC142266 for ; Mon, 15 Jan 2007 15:16:13 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04193-01 for ; Mon, 15 Jan 2007 15:16:11 -0800 (PST) Received: from [10.1.1.218] (ip10.commerce.net [157.22.41.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 1BCF714225C for ; Mon, 15 Jan 2007 15:16:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <953beacc0701081749n46286f41ic500ebf96d33ee9d@mail.gmail.com> References: <953beacc0701081749n46286f41ic500ebf96d33ee9d@mail.gmail.com> Message-Id: From: Lisa Dusseault Date: Mon, 15 Jan 2007 15:16:09 -0800 To: Message Notifications interest group discussion list X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a9ddb14fac983e71b59f23b52a45b4e Subject: [Notifications] Setting up email event streams X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0929419216==" Errors-To: notifications-bounces@ietf.org --===============0929419216== Content-Type: multipart/alternative; boundary=Apple-Mail-29--530275148 --Apple-Mail-29--530275148 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I've been meaning to send this out more broadly after a bit of private comment: two quite different models for setting up event streams based on what's easier to authenticate -- the event stream "owner" (in this case the mailbox owner) or the stream recipient. I hope it helps compare different approaches. Lisa --- The goal is to start (and stop) events flowing from an event source (in our case, an email server) to the event sink, frequently using a system with an explicit event relay. Because there are often three parties required in an event flow , we have to pick some way for the three parties to coordinate. The three parties are the event source (an email server), the event sink (a client, perhaps not an email client) and an event relay. The event relay has many users thus it has addresses for each user and possibly also addresses for devices/clients. Two kinds of application-layer explicit event relays are starting to be common: XMPP and SIP. For the purposes of considering an event feed setup model, we do not want to be concerned about the mostly orthogonal issue of what protocol to use to talk to event relay. So for now we assume that event relays have all features common to XMPP and SIP (addresses, pub/sub features, event stream aggregation). Choosing between two event stream setup models requires assumptions about - what kind of authorization is easier or more important to provide - whether there are a lot of different event sink addressess - whether direct access to the event source is always/usually available (can be affected by whether the event source is publicly available) - whether event flows stop and start frequently, or can simply be turned on for a very long term MODEL A. SUBSCRIBE Chain A-1 Description In this model, when a user decides to get an email event flow to a particular device or piece of software, the user typically works with the event sink interface to indicate where to get the events from. Then a SUBSCRIBE message of some kind gets generated by the event sink, sent to the event relay and is handled by the event source. A-2 Authorization issue The authorization problem here is to determine if the address that the SUBSCRIBE message comes from is permitted to receive these events. In the case of a publicly-subscribable resource this problem disappears. In many email use cases, only a small number of event sink addresses will be authorized to receive event notifications -- perhaps the event source (the email server) can simply be configured with a short allowed list of event recipients that doesn't change often (e.g. my personal IM address, my work address, and the one used by my phone provided by my phone service provider). Some SUBSCRIBE systems have the ability to provide a PENDING response to a subscription. This is used when an out-of-band mechanism is initiated to authorize the subscribing address. In an email event source use case, one obvious out-of-band mechanism is for the email server to create an email with a link saying "Click here to authorize this subscription". It's also possible to use a mechanism like URLAUTH to prove authorization -- in this approach, the subscriber provides a URL that has a secret token in it authorizing the subscription. It's possible that this would authorize the subscribing address for future subscriptions as well, or only for a limited period. A-3 Drawbacks: a) Only some notification protocols support SUBSCRIBE semantics. b) Complicated filters and event types (to support use cases like "Alert me on event type 'email arrives' if it is from my boss, has my full email address or the address of the developer list on the to line, and the subject does not begin with 'FUNNY'..." ) might need a little extra work. Both SIP and XMPP subscriptions can be extended in such a way that existing notification relays would pass on a filter specification in whatever language/format most appropriate for email. It might even be possible to send SIEVE conditionals in the body of the SUBSCRIBE message. XMPP has notification nodes in XEP-0060 and notification filters in XEP-0163. A-4 Advantages b) Allows for frequent starting and stopping of subscriptions, possibly an efficiency/scaling concern MODEL B. Sender RULES B-1 Description In this model, the user typically works with the event source in order to configure it to send events to a given set of addresses. For example, the user might have access to a Web interface to an email server where it can say "Send new message notifications to xmpp://lisa@psg.com" or someday use MANAGESIEVE. B-2 Authorization issue The authorization problem here is to determine if the user creating the sending rule is authorized to send an event stream to the receiving address. If anybody can send to the receiving address (e.g. email) then it's publicly addressable and the problem disappears. Many kinds of addresses are publicly addressable and use whitelisting together with asking permission ("do you wish to allow messages from this source in the future"). B-3 Drawbacks: a) Only some event sources support RULE systems. We are building SIEVE for email clients and servers but it may be harder to generalize this beyond email clients and servers. Even sticking strictly the proposed scope of email server sources, we have to consider whether a client such as a calendar client (subscribing for IMIP messages) or a time-management dashboard (subscribes to "unread" counts but doesn't otherwise read email) are going to be able to implement SIEVE, authenticate to mail servers etc. b) If sender rules are setup through Web interfaces, users are definitely not going to turn them on and off frequently. c) Failure feedback: how does the event source let the user know that some address keeps bouncing? --Apple-Mail-29--530275148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I've been meaning to send = this out more broadly after a bit of private comment: two quite = different models for setting up event streams based on what's easier to = authenticate -- the event stream "owner" (in this case the mailbox = owner) or the stream recipient.=A0 I hope it helps compare different = approaches.

Lisa

---

The goal is to start (and = stop) events flowing from an event source (in our case, an email server) = to the event sink, frequently using a system with an explicit event = relay. =A0 = Because there = are often three parties required in an event flow , we have to pick some = way for the three parties to coordinate.

The three parties are the = event source (an email server), the event sink (a client, perhaps not an = email client)=A0= and an event = relay.=A0 = The event = relay has many users thus it has addresses for each user and possibly = also addresses for devices/clients.=A0 Two kinds of application-layer explicit event relays = are starting to be common: XMPP and SIP.=A0 For the purposes of = considering an event feed setup model, we do not want to be concerned = about the mostly orthogonal issue of what protocol to use to talk to = event relay.=A0 = So for now we = assume that event relays have all features common to XMPP and SIP = (addresses, pub/sub features, event stream = aggregation).

Choosing between two event stream setup models = requires assumptions about
- what kind of = authorization is easier or more important to provide
- whether there are a lot of different event sink = addressess
- whether direct access to the event source is = always/usually available (can be affected by whether the event source is = publicly available)
- whether event flows stop = and start frequently, or can simply be turned on for a very long = term

MODEL A.=A0 SUBSCRIBE Chain

A-1= Description

In = this model, when a user decides to get an email event flow to a = particular device or piece of software, the user typically works with = the event sink interface to indicate where to get the events = from.=A0 = Then a = SUBSCRIBE message of some kind gets generated by the event sink, sent to = the event relay and is handled by the event source.

A-2 Authorization = issue

The= authorization problem here is to determine if the address that the = SUBSCRIBE message comes from is permitted to receive these = events.=A0 = In the case of = a publicly-subscribable resource this problem disappears.=A0 In many email use cases, = only a small number of event sink addresses will be authorized to = receive event notifications -- perhaps the event source (the email = server) can simply be configured with a short allowed list of event = recipients that doesn't change often (e.g. my personal IM address, my = work address, and the one used by my phone provided by my phone service = provider).

Some SUBSCRIBE systems have the ability to provide a = PENDING response to a subscription.=A0 This is used when an out-of-band mechanism is = initiated to authorize the subscribing address.=A0 In an email event source = use case, one obvious out-of-band mechanism is for the email server to = create an email with a link saying "Click here to authorize this = subscription".

It's also possible to use a mechanism like URLAUTH to = prove authorization -- in this approach, the subscriber provides a URL = that has a secret token in it authorizing the subscription.=A0 It's possible that this = would authorize the subscribing address for future subscriptions as = well, or only for a limited period.

A-3= Drawbacks:
=A0=A0 a)=A0 Only some notification = protocols support SUBSCRIBE semantics.

=A0=A0 b)=A0 Complicated filters and = event types (to support use cases like "Alert me on event type 'email = arrives' if it is from my boss, has my full email address or the address = of the developer list on the to line, and the subject does not begin = with 'FUNNY'..." )=A0 might need a little extra work.=A0 Both SIP and XMPP = subscriptions can be extended in such a way that existing notification = relays would pass on a filter specification in whatever language/format = most appropriate for email.=A0 It might even be possible to send SIEVE conditionals = in the body of the SUBSCRIBE message.=A0 XMPP has notification nodes = in XEP-0060 and notification filters in XEP-0163.

A-4 = Advantages
=A0=A0 b) Allows for frequent starting and stopping of = subscriptions, possibly an efficiency/scaling concern


MODEL B. Sender RULES

B-1 = Description

In = this model, the user typically works with the event source in order to = configure it to send events to a given set of addresses.=A0 For example, the user might = have access to a Web interface to an email server where it can say "Send = new message notifications to xmpp://lisa@psg.com" or someday use = MANAGESIEVE.

B-2= Authorization issue

The= authorization problem here is to determine if the user creating the = sending rule is authorized to send an event stream to the receiving = address.=A0 = If anybody can = send to the receiving address (e.g. email) then it's publicly = addressable and the problem disappears.=A0 Many kinds of addresses are = publicly addressable and use whitelisting together with asking = permission ("do you wish to allow messages from this source in the = future").

B-3= Drawbacks:
=A0=A0 a) Only some event sources = support RULE systems.=A0 We are building SIEVE for email clients and servers = but it may be harder to generalize this beyond email clients and = servers.=A0 = Even sticking = strictly the proposed scope of email server sources, we have to consider = whether a client such as a calendar client (subscribing for IMIP = messages) or a time-management dashboard (subscribes to "unread" counts = but doesn't otherwise read email) are going to be able to implement = SIEVE, authenticate to mail servers etc.

=A0=A0 b) If sender rules are = setup through Web interfaces, users are definitely not going to turn = them on and off frequently.

=A0= =A0 c) Failure = feedback: how does the event source let the user know that some address = keeps bouncing?

=A0





= --Apple-Mail-29--530275148-- --===============0929419216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications --===============0929419216==-- From notifications-bounces@ietf.org Tue Jan 16 13:35:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t9m-0005EC-A1; Tue, 16 Jan 2007 13:35:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6t9k-0005E1-OJ for notifications@ietf.org; Tue, 16 Jan 2007 13:35:36 -0500 Received: from web30511.mail.mud.yahoo.com ([68.142.201.239]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H6t9g-0007IQ-CJ for notifications@ietf.org; Tue, 16 Jan 2007 13:35:36 -0500 Received: (qmail 68783 invoked by uid 60001); 16 Jan 2007 18:35:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=a7MnoUS0prWMwp02GW1mZZY+z5V+PBLq0LFvmzp5IQvlgZQWKQclK20ffdTK/PueuEhb2D58d01ZQcMzIQ/mwy3IRozv3CSfNNrVkbj1P3eN9V/gnykFQV7DtR33YOBMiiiVPBSRNdxW4Lig1cByFDeYZXqXPNckstdSWpYtiBQ= ; Message-ID: <20070116183531.68781.qmail@web30511.mail.mud.yahoo.com> Received: from [194.209.131.192] by web30511.mail.mud.yahoo.com via HTTP; Tue, 16 Jan 2007 10:35:31 PST Date: Tue, 16 Jan 2007 10:35:31 -0800 (PST) From: Eric Burger To: notifications@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Notifications] Notifications Jabber Chat X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Burger List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0106057793==" Errors-To: notifications-bounces@ietf.org --===============0106057793== Content-Type: multipart/alternative; boundary="0-1800637312-1168972531=:61903" --0-1800637312-1168972531=:61903 Content-Type: text/plain; charset=ascii Content-Transfer-Encoding: quoted-printable Apologies to Randy, but it looks like the 25th is the day.=0A=0AAlso, apolo= gies to the list for sending in HTML. It's the only way I know of sending = the URL's without them line breaking.=0A=0AI'm too lazy to try to get a not= ifications Jabber room setup, so we will use the lemonade room:=0A=0AServer= : jabber.ietf.org=0ARoom: lemonade=0ALogs: =0A=0ATime and Date:=0A10:00am Eastern Time, 25 January 2= 007=0A=0A=0AAgenda:=0ADiscuss= goals and scope=0A=0A=0A=0A=0A=0A =0A_____________________________________= _______________________________________________=0ANever Miss an Email=0ASta= y connected with Yahoo! Mail on your mobile. Get started!=0Ahttp://mobile.= yahoo.com/services?promote=3Dmail --0-1800637312-1168972531=:61903 Content-Type: text/html; charset=ascii Content-Transfer-Encoding: quoted-printable
Apologies to Randy, but it looks like the 25th is the = day.

Also, apologies to the list for sending in HTML.  It's the= only way I know of sending the URL's without them line breaking.

I'= m too lazy to try to get a notifications Jabber room setup, so we will use = the lemonade room:

Server: jabber.ietf.org
Room: lemonade
Logs: <http://www.ietf.org/meetings/ietf-logs/lemonade/>

Time and Date:
10:00am Eastern Time, 25 January 2007
<http://www.timeanddate.com/worldclock/fixedtime.html?month=3D1&day=3D= 25&year=3D2007&hour=3D10&min=3D0&sec=3D0&p1=3D43>= ;

Agenda:
Discuss goals and scope


= =0A=0A
We won't tell. Get more on shows you hate to= love
(and love to hate): Yahoo! TV's Guilty Pleasures l= ist. --0-1800637312-1168972531=:61903-- --===============0106057793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications --===============0106057793==-- From notifications-bounces@ietf.org Thu Jan 18 20:11:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iHf-0000Bs-6A; Thu, 18 Jan 2007 20:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iHe-0000Bj-S3 for notifications@ietf.org; Thu, 18 Jan 2007 20:11:10 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7iHa-0006YQ-Dh for notifications@ietf.org; Thu, 18 Jan 2007 20:11:10 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l0J13NC06774 for ; Thu, 18 Jan 2007 20:03:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Notifications] Notifications Jabber Chat Date: Thu, 18 Jan 2007 20:11:10 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0DED58B9@zcarhxm0.corp.nortel.com> In-Reply-To: <20070116183531.68781.qmail@web30511.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Notifications Jabber Chat Thread-Index: Acc5nSjiBAAjYBfKTw+xlnNP4kHGxwBySjKA From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174158717==" Errors-To: notifications-bounces@ietf.org This is a multi-part message in MIME format. --===============0174158717== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73B66.B09D4EE1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73B66.B09D4EE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 Is there any interest to have an audio channel for this discussion as well?=20 =20 I can set one up if that would be helpful. =20 Cheers, Glenn. ________________________________ From: Eric Burger [mailto:ewburger@yahoo.com]=20 Sent: Tuesday, January 16, 2007 1:36 PM To: notifications@ietf.org Subject: [Notifications] Notifications Jabber Chat Apologies to Randy, but it looks like the 25th is the day. Also, apologies to the list for sending in HTML. It's the only way I know of sending the URL's without them line breaking. I'm too lazy to try to get a notifications Jabber room setup, so we will use the lemonade room: Server: jabber.ietf.org Room: lemonade Logs: Time and Date: 10:00am Eastern Time, 25 January 2007 Agenda: Discuss goals and scope ________________________________ We won't tell. Get more on shows you hate to love = =20 (and love to hate): Yahoo! TV's Guilty Pleasures list. = =20 ------_=_NextPart_001_01C73B66.B09D4EE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Folks,
 
Is=20 there any interest to have an audio channel for this discussion as=20 well? 
 
I can=20 set one up if that would be helpful.
 
Cheers,
Glenn.

From: Eric Burger = [mailto:ewburger@yahoo.com]=20
Sent: Tuesday, January 16, 2007 1:36 PM
To:=20 notifications@ietf.org
Subject: [Notifications] Notifications = Jabber=20 Chat

Apologies to Randy, but it looks like the 25th is the = day.

Also,=20 apologies to the list for sending in HTML.  It's the only way I = know of=20 sending the URL's without them line breaking.

I'm too lazy to try = to get=20 a notifications Jabber room setup, so we will use the lemonade=20 room:

Server: jabber.ietf.org
Room: lemonade
Logs: = <http://www.ietf.org/meetings/ietf-logs/lemonade/><= /SPAN>

Time=20 and Date:
10:00am Eastern Time, 25 January 2007
<http://www.timeanddate.com/worldclock/fixedtime.html?mont= h=3D1&day=3D25&year=3D2007&hour=3D10&min=3D0&sec=3D0&= amp;p1=3D43>

Agenda:
Discuss=20 goals and scope


We won't tell. Get more on shows=20 you hate to love
(and love to hate): Yahoo!=20 TV's Guilty Pleasures list. ------_=_NextPart_001_01C73B66.B09D4EE1-- --===============0174158717== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications --===============0174158717==-- From notifications-bounces@ietf.org Mon Jan 22 15:44:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H961T-0005F2-BM; Mon, 22 Jan 2007 15:44:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H961S-0005Ef-Aw for notifications@ietf.org; Mon, 22 Jan 2007 15:44:10 -0500 Received: from wx-out-0506.google.com ([66.249.82.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H961O-0006Qa-2X for notifications@ietf.org; Mon, 22 Jan 2007 15:44:10 -0500 Received: by wx-out-0506.google.com with SMTP id h31so1438406wxd for ; Mon, 22 Jan 2007 12:44:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=efa4emxhuVlHynHz/FbFFw3nS0loR7QdeIqvbIQOeoBfuNxB1D6f9qPZGi+1lUZ+szJLPnuGoHllGXRuc9BYMGfzK3dnbKet+Y7HXMLeNZNTIh9xDt/1RH0RGKmYDj4yowiEtIBdQTlk/xjHgC23+nWhkg4rVpPtMUcWeBYnc2w= Received: by 10.70.50.10 with SMTP id x10mr11507750wxx.1169498645025; Mon, 22 Jan 2007 12:44:05 -0800 (PST) Received: by 10.70.130.13 with HTTP; Mon, 22 Jan 2007 12:44:04 -0800 (PST) Message-ID: <953beacc0701221244h522b5c0asf509a2f21e49fe23@mail.gmail.com> Date: Mon, 22 Jan 2007 12:44:04 -0800 From: "Rohan Mahy" To: "Glenn Parsons" Subject: Re: [Notifications] Notifications Jabber Chat In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0DED58B9@zcarhxm0.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070116183531.68781.qmail@web30511.mail.mud.yahoo.com> <085091CB2CA14E4B8B163FFC37C84E9D0DED58B9@zcarhxm0.corp.nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: notifications@ietf.org X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Seems useful to me. thanks, -rohan On 1/18/07, Glenn Parsons wrote: > > > Folks, > > Is there any interest to have an audio channel for this discussion as well? > > I can set one up if that would be helpful. > > Cheers, > Glenn. > > ________________________________ > From: Eric Burger [mailto:ewburger@yahoo.com] > Sent: Tuesday, January 16, 2007 1:36 PM > To: notifications@ietf.org > Subject: [Notifications] Notifications Jabber Chat > > > > > Apologies to Randy, but it looks like the 25th is the day. > > Also, apologies to the list for sending in HTML. It's the only way I know > of sending the URL's without them line breaking. > > I'm too lazy to try to get a notifications Jabber room setup, so we will use > the lemonade room: > > Server: jabber.ietf.org > Room: lemonade > Logs: > > Time and Date: > 10:00am Eastern Time, 25 January 2007 > > > Agenda: > Discuss goals and scope > > > ________________________________ > We won't tell. Get more on shows you hate to love > (and love to hate): Yahoo! TV's Guilty Pleasures list. > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > https://www1.ietf.org/mailman/listinfo/notifications > > > _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications