From notifications-bounces@ietf.org Sun Jul 01 21:29:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5AjL-00043M-OT; Sun, 01 Jul 2007 21:29:31 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I5AjK-00043C-HD for notifications-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 21:29:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5AjK-000434-7j for notifications@ietf.org; Sun, 01 Jul 2007 21:29:30 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5AjF-0004QU-W8 for notifications@ietf.org; Sun, 01 Jul 2007 21:29:30 -0400 Received: by an-out-0708.google.com with SMTP id c17so305641anc for ; Sun, 01 Jul 2007 18:29:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=a/355gaIC43zCgQCqwX+O+penkp02BkEGHS10Pr5v8RLr0j3sFHrVFj+OfnPHNkM0gLhwo9Bt/fiG/9t9F0W5mFbRppzdzGx9GmlgrVbbq/cQhMF6OLngU+AuvOxSDEbwF112Pfg+9xGQjHzC86j06qu6pIiKpdmeFJ9w1sORBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=YKFwUYlg0FKKBlo8cOBA4YZx7RRzAZwwHGb8ftVsm8xfz12p+p5KmVqBzeRXsBXi930TkhYNTQ27hWveNVkvpDgSePaHa3C6Ha5pZE5ThlVQHb9Z7WfUd8qQdDVijE+V4UdZK4BwXUzyvqk7FbnRGo9NEeyOqAN+trvXNlLrq6A= Received: by 10.100.142.12 with SMTP id p12mr3390667and.1183339765590; Sun, 01 Jul 2007 18:29:25 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Sun, 1 Jul 2007 18:29:25 -0700 (PDT) Message-ID: <953beacc0707011829g5c358399l83bce7e7d8469a62@mail.gmail.com> Date: Sun, 1 Jul 2007 18:29:25 -0700 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: de4f315c9369b71d7dd5909b42224370 Subject: [Notifications] SIP Sieve notification draft actually submitted 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 made a small change to the sip-based sieve notification draft that I discussed in Prague during lemonade. The draft now mentions Lisa's model document and the lemonade catalog of message system events. The mechanism is still the same. Please accept my apologies that I forgot to submit it last time. I would be very keen to discuss why this is mechanism is or is not appropriate, but I suspect that this is actually quite easy to implement. thanks, -rohan 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 _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jul 02 10:59:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5NNA-0006Cw-QM; Mon, 02 Jul 2007 10:59:28 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I57wr-0004i5-BJ for notifications-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 18:31:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I57wr-0004hx-0M for Notifications@ietf.org; Sun, 01 Jul 2007 18:31:17 -0400 Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I57wm-0004K9-8m for Notifications@ietf.org; Sun, 01 Jul 2007 18:31:16 -0400 Received: from [127.0.0.1] (figas.ekabal.com [204.61.215.10]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id l61MV1p24341; Sun, 1 Jul 2007 15:31:01 -0700 In-Reply-To: <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 Date: Sun, 1 Jul 2007 15:31:00 -0700 To: Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 X-Mailman-Approved-At: Mon, 02 Jul 2007 10:59:27 -0400 Cc: Rohan Mahy , 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 Hi Lisa, Sorry it took me so long to get back to your comments. I also noticed one other thing. The CNA and the client could be in the same domain, so the domain boundary in your diagram between these two is optional. Comments inline. On Jun 29, 2007, at 2:33 PM, Lisa Dusseault wrote: > Hi Rohan, > > I'm working through your comments and they're definitely going to > help do a much better 2nd rev. I hope they do help. > On Jun 19, 2007, at 11:39 AM, Rohan Mahy wrote: > >> HI, >> >> Attached are some comments after my read of >> draft-dusseault-email-notif-model-00. ... >> >> The significance of the separation between PNA and CNA as other than >> logical roles escaped me until the end of Section 3.3. In addition, >> the way it is described there is biased by XMPP mental models so >> it is >> hard to explain in SIP terms. I don't think it would be hard to come >> up with some text that makes it clear in protocol neutral terms what >> the separation needs to be. I think the key distinction is that in >> XMPP pubsub, the default interdomin model includes aggregation, >> but in >> the SIP notification model, the default interdomain model does not. >> This means that SIP scales more poorly without an aggregation >> extension in the typical case where the content is the same for all >> subscribers, and that XMPP needs an extension to handle notification >> content that differs based on the identity of the subscriber. > > I'm going to need more help describing this in a way that suits > both XMPP and SIP -- possibly this is one of those details that has > to be described separately for each. I don't think these need to be defined separately. I will try to provide some concrete proposals here: For one thing, the sub-pub terminology is XMPP-specific. Both SIP and XMPP have a concept of a subscription. Both have events generated about those subscriptions. In XMPP these events are pubs; in SIP these events are notifications. In SIP, a publication is a completely different thing entirely (it is a push). So, in your diagram, you could replace "publish" with "event" throughout. The PNA term still works fine since in XMPP it is aggregating *for* pubs and in SIP it is aggregating *from* pubs. :-) > the subscription request is an implicit authorization, along each > step of the publish-subscribe chain In SIP, the subscription request would likely go directly to the PNA. The CNA would merely verify the identity claimed by the client and forward the subscription request to the PNA. Instead, I propose "the subscription request contains an implicit authorization, by the client and the CNA". This should work for both. > My confusion here is that the architecture I propose does not > demand interdomain aggregation. I've tried to make it more clear > that the PNA is responsible for fanout of events (aggregation of > subscriptions is the flipside of fanout of events) but I didn't > require the CNA to also do so. This does not jive with the expansion of the CNA acronym. The "A" in CNA stands for *Aggregator*? What is the CNA aggregating if the PNA is already aggregating everything? > Not that I think it matters for this document, but I am not > convinced that XMPP requires an extension to handle notification > content that differs based on the identity of the subscriber. I > can't quite dredge up the details right now though. > > >> Sect 3.1 >> "NOTIF=sip.example.com" should be a URI, not a service name (ex: >> "NOTIF=sip:resource@server.example.com") including an optional >> userpart. > > What would be most SIPpish for the "resource" part above? Would > there be something like a user name there, or a mailbox name, or both? probably a user name. For example: sip:alice@server.example.com For XMPP, I think a fully qualified jid pointing to the notification resource would make sense. >> It also seems useful to mention SIP and XMPP specific discovery >> mechanisms here briefly. For SIP, callee caps and caller prefs is >> one >> mechanism, and the SIP profile configuration mechanism is another >> (though the later is only feasible for discovering notification >> servers in the same domain). You mention disco in section 5, but it >> might deserve a mention here. >> > Can you give me a reference for callee caps? RFC 3840 . The official title changed pretty late, so I still think of it as callee-caps. > I know that RFC3841 is Caller Preferences for SIP, but how would > that be used or what problems would it solve here? If the Authoritative SIP proxy server for "example.com" is configured to know about the PNA, the proxy can configure what looks like a static registration for the PNA. Contact: ;methods="SUBSCRIBE" ;events="message-summary" ;type="application/x-foobar-notification-format" Then when a subscribe comes in, a proxy doing Caller Preferences routing, can use the presence of the method in the request, the event name in the Event header, and the notification body format in the Accept header to route to a UA instance that can handle that type of Event. SUBSCRIBE sip:alice@example.com SIP/2.0 Event: message-summary Accept: application/x-foobar-notification-format >> Sect 3.2 >> "In some cases, users will have to provide mailbox names when >> subscribing. For example, to configure a message waiting indicator >> status bar applet for a laptop, the user will have to provide not >> only the mail server address but also the user login for the email >> server, password and mailbox name unless that is assumed to be the >> same as the user login." >> The PNA or CNA may use an alternate form of identity and >> authentication (SIP Identity header, XMPP from attribute, SAML >> assertion, or OpenID URI) instead of the credentials used to >> authenticate the mail server itself. > > I need to read http://www.ietf.org/rfc/rfc4474.txt. More work > definitely needed here. I think the important thing to mention is that the PNA can use local administrative policy to decide whether the identity of the subscriber is considered equivalent to the owner of the mailbox, or is otherwise explicitly authorized to receive notifications. Providing the user login an password could actually make the overall system security worse instead of better. >> Sect 4: The Event header is usually not the primary descriptor of >> the >> resource of interest. The Request URI is the primary descriptor. >> The >> resource (the user part of the Req URI) should contain at least >> enough >> information to identify the email server and the mail account. It >> could contain the mailbox of interest as well, but i don;t think that >> is a good idea. The subscriber could be interested in multiple >> mailboxes; so the SUBSCRIBE body seems like the best place to put >> this. Of course, a default of INBOX and all new messages could be >> assumed if no SUBSCRIBE body is attached. > > I think I follow this but I'm not sure how to reword the text. Can > you suggest a pointer to a primer that might have better > introductory description of event packages, or wording of your > own? I've read the RFC on SIP event packages a couple times but > that doesn't mean I can describe it the way a SIPper would. For email event notifications, clients specify which user or resource and which server or domain is the target of its SUBSCRIBE request, and place this in a SIP URI called the Request URI. The client also specifies the name of the Event package, and what notification formats are acceptable. If the subscription request needs to specify a particular mailbox, the event package could define a new SUBSCRIBE body format or an extra parameter to the Event header. A SUBSCRIBE body always acts as a filter for the specific subscription. >> Sect 5.1: i think the XMPP forms functionality is still useful in >> this >> context, but it is just used a way to provide a human readable way to >> configure part of the server, which behind the scenes uses the >> well-known event types. >> >> Sect 6: I think it is VERY important to clarify that SOME sieve >> notifications could be unsolicited and some could be explicitly >> requested. The SIP notification draft I wrote deals with explicitly >> requested sieve notifications, but I suspect most readers of >> section 6 >> would think that this is impossible. > > It's impossible today; if we decide to standardize SIP handling of > SIEVE scripts or Email server accepting SUBSCRIBE requests it might > become possible... The benefit/cost tradeoffs for doing this don't > seem right to me and I'll attempt to explain why in the next version. "It's impossible today" is both untrue and a red herring. I think what you mean is "it isn't standardized today" which is irrelevant, since we are discussing developing new protocols and data formats. As I demonstrated in my draft, I can write a PNA-like notifier and a SIP client that do this today without having to define any new IETF protocols. I would have to use a vendor-specific MIME type and schema and I would use the sieve notification verb with a URI scheme which is not documented in any sieve spec. This doesn't even present a process barrier. The much more important question is why do so many people in the email community feel that processing a per-subscription sieve document for this purpose (as opposed to an arbitrary sieve document) is a problem? It is extremely cheap to generate on the client, and it still scales linearly with the number of users and messages on the PNA. As for the next version of the draft, I strongly suggest that you make the following two changes: 1) drop the word SIEVE from the title of Section 6. 2) in Section 2.1: s/This architecture ignores the existence of SIEVE and SIEVE- generated events until section 6, as these are necessarily unsolicited notification rather than pub-sub notifications. /This architecture ignores and defers discussion of unsolicited notifications generated by SIEVE or other sources until Section 6./ thanks, -rohan _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jul 02 11:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5O3x-0008No-L0; Mon, 02 Jul 2007 11:43:41 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I5O3x-0008Nf-3C for notifications-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 11:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5O3w-0008NW-Ps for Notifications@ietf.org; Mon, 02 Jul 2007 11:43:40 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5O3s-0000dY-Ay for Notifications@ietf.org; Mon, 02 Jul 2007 11:43:40 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 9FF252651; Mon, 2 Jul 2007 15:42:33 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID787LgBPQh9386Xo2; Mon, 02 Jul 2007 15:42:33 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID787LgBPQh9386Xo2 Received: from [192.168.1.100] ([74.95.2.169]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 09:41:50 -0600 In-Reply-To: <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <20203FBC-3DC7-454B-8428-12658EEC55B3@commerce.net> From: Lisa Dusseault Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 Date: Mon, 2 Jul 2007 08:43:29 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Jul 2007 15:41:50.0332 (UTC) FILETIME=[81A6DBC0:01C7BCBF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: , Content-Type: multipart/mixed; boundary="===============0764654446==" Errors-To: notifications-bounces@ietf.org --===============0764654446== Content-Type: multipart/alternative; boundary=Apple-Mail-5-1072863069 --Apple-Mail-5-1072863069 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote: > >> My confusion here is that the architecture I propose does not >> demand interdomain aggregation. I've tried to make it more clear >> that the PNA is responsible for fanout of events (aggregation of >> subscriptions is the flipside of fanout of events) but I didn't >> require the CNA to also do so. > This does not jive with the expansion of the CNA acronym. The "A" > in CNA stands for *Aggregator*? What is the CNA aggregating if the > PNA is already aggregating everything? I could have used the word proxy or server and I'm not sure why I didn't. I expect sometimes the software the CNA and the PNA are running will be just the same, only their role will be different. So I would rather not use "Consumer Notification Server" and "Publisher Notifications Aggregator" or readers will think it is two specialized servers. Is "Server" better for both? Aren't there cases where a SIP CNA will act as an aggregator and forward events to more than one device? It's not required of the CNA, but isn't it likely? Lisa --Apple-Mail-5-1072863069 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jul 1, 2007, at = 3:31 PM, Rohan Mahy wrote:


My confusion here is that the = architecture I propose does not demand interdomain aggregation.=A0 I've tried to make it more = clear that the PNA is responsible for fanout of events (aggregation of = subscriptions is the flipside of fanout of events) but I didn't require = the CNA to also do so.

This does not jive with the expansion of the CNA = acronym. The "A" in CNA stands for *Aggregator*?=A0 What is the CNA aggregating = if the PNA is already aggregating everything?

=

I could have used the word proxy or server = and I'm not sure why I didn't.=A0 I expect sometimes the software the = CNA and the PNA are running will be just the same, only their role will = be different.=A0 So I would rather not use "Consumer Notification = Server" and "Publisher Notifications Aggregator" or readers will think = it is two specialized servers.=A0 Is "Server" better for = both?

Aren't = there cases where a SIP CNA will act as an aggregator and forward events = to more than one device?=A0 It's not required of the CNA, but isn't it = likely?

Lisa
= --Apple-Mail-5-1072863069-- --===============0764654446== 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 --===============0764654446==-- From notifications-bounces@ietf.org Mon Jul 02 11:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OBT-0005aw-3l; Mon, 02 Jul 2007 11:51:27 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I5OBR-0005ao-NS for notifications-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 11:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OBR-0005ag-Dp for Notifications@ietf.org; Mon, 02 Jul 2007 11:51:25 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5OBL-0001b2-Ub for Notifications@ietf.org; Mon, 02 Jul 2007 11:51:25 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 4E72327AE; Mon, 2 Jul 2007 15:51:19 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID650LgBPzT0082Xo1; Mon, 02 Jul 2007 15:51:19 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID650LgBPzT0082Xo1 Received: from [192.168.1.100] ([74.95.2.169]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 09:49:35 -0600 In-Reply-To: <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lisa Dusseault Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 Date: Mon, 2 Jul 2007 08:51:17 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Jul 2007 15:49:35.0936 (UTC) FILETIME=[972C6400:01C7BCC0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Content-Type: multipart/mixed; boundary="===============1317165198==" Errors-To: notifications-bounces@ietf.org --===============1317165198== Content-Type: multipart/alternative; boundary=Apple-Mail-6-1073331129 --Apple-Mail-6-1073331129 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote: > >> I know that RFC3841 is Caller Preferences for SIP, but how would >> that be used or what problems would it solve here? > > If the Authoritative SIP proxy server for "example.com" is > configured to know about the PNA, the proxy can configure what > looks like a static registration for the PNA. > > Contact: ;methods="SUBSCRIBE" > ;events="message-summary" > ;type="application/x-foobar-notification-format" > > Then when a subscribe comes in, a proxy doing Caller Preferences > routing, can use the presence of the method in the request, the > event name in the Event header, and the notification body format in > the Accept header to route to a UA instance that can handle that > type of Event. > > SUBSCRIBE sip:alice@example.com SIP/2.0 > Event: message-summary > Accept: application/x-foobar-notification-format Trying to be sure I understand this here. You're assuming that the authoritative SIP proxy server for example.com is a different server than the "PNA" for example.com, right? I had been thinking these were often -- but not necessarily -- the same server. If these are the same server, then the static registration isn't necessary, of course. If these are not the same server, then why isn't this just transparent to everybody outside the example.com administrative domain? thanks, Lisa --Apple-Mail-6-1073331129 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jul 1, 2007, at = 3:31 PM, Rohan Mahy wrote:


I know that RFC3841 is Caller = Preferences for SIP, but how would that be used or what problems would = it solve here?


If the Authoritative SIP = proxy server for "example.com" is configured to know about the PNA, the = proxy can configure what looks like a static registration for the = PNA.


Contact: = <sip:pna.example.com>;methods=3D"SUBSCRIBE"

=A0;events=3D"message-summary"

=A0;type=3D"application/x-foobar-no= tification-format"


Then when a subscribe comes = in, a proxy doing Caller Preferences routing, can use the presence of = the method in the request, the event name in the Event header, and the = notification body format in the Accept header to route to a UA instance = that can handle that type of Event.


=

SUBSCRIBE sip:alice@example.com = SIP/2.0

Event: = message-summary

Accept: application/x-foobar-notification-format

=


Trying to be sure I = understand this here.=A0 You're assuming that the authoritative SIP = proxy server for example.com is a different server than the "PNA" for = example.com, right?=A0 I had been thinking these were often -- but not = necessarily -- the same server.=A0 =A0If these are the same server, then = the static registration isn't necessary, of course.=A0 =A0If these are = not the same server, then why isn't this just transparent to everybody = outside the example.com administrative domain?

thanks,
Lisa
<= /BODY>= --Apple-Mail-6-1073331129-- --===============1317165198== 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 --===============1317165198==-- From notifications-bounces@ietf.org Mon Jul 02 15:12:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKE-0008Ps-CV; Mon, 02 Jul 2007 15:12:42 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I5RKC-0008PX-SF for notifications-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 15:12:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKC-0008PP-Ii for Notifications@ietf.org; Mon, 02 Jul 2007 15:12:40 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RK4-0002hB-EL for Notifications@ietf.org; Mon, 02 Jul 2007 15:12:40 -0400 Received: by an-out-0708.google.com with SMTP id c17so357841anc for ; Mon, 02 Jul 2007 12:12:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CapIVNv768yKJn7P/fQOntI85/TgpBnuGpVlb6R1FKjbvXn+LNICBpq45GAM+SHgu9dh3FoGHgH2hcsyQtcQ1ZECM6wU6Sri+osNQJ69jlhy08X7z0q5a9aYUlm/O1HCrbk+UPjAfx42+0YrFIc5TYnne4RzAh67ZZAmWgffwiI= 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=qGfxXaXbePdZGGF0+sOr210UBFfgGR0YIHKMYOsV61+DysVZHRT3wGlNz70ABZsYk1ukwDEU87BqmaXarwXRRGnGfkcqf24upP04zTuNFG4jWqKQVhkY5tmtB+OJtvfW1NxErfvaheyjG8EKF5KFk51f3xsBpy+F65tW4lEXKVU= Received: by 10.100.123.9 with SMTP id v9mr3438587anc.1183403551205; Mon, 02 Jul 2007 12:12:31 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Mon, 2 Jul 2007 12:12:31 -0700 (PDT) Message-ID: <953beacc0707021212r1cb63fc4i796017d20dcbf8f9@mail.gmail.com> Date: Mon, 2 Jul 2007 12:12:31 -0700 From: "Rohan Mahy" To: "Lisa Dusseault" Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Rohan Mahy , 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 On 7/2/07, Lisa Dusseault wrote: > On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote: > > I know that RFC3841 is Caller Preferences for SIP, but how would that be > used or what problems would it solve here? > > If the Authoritative SIP proxy server for "example.com" is configured to > know about the PNA, the proxy can configure what looks like a static > registration for the PNA. > > Contact: ;methods="SUBSCRIBE" > ;events="message-summary" > ;type="application/x-foobar-notification-format" > > Then when a subscribe comes in, a proxy doing Caller Preferences routing, > can use the presence of the method in the request, the event name in the > Event header, and the notification body format in the Accept header to route > to a UA instance that can handle that type of Event. > > SUBSCRIBE sip:alice@example.com SIP/2.0 > Event: message-summary > Accept: application/x-foobar-notification-format > > Trying to be sure I understand this here. You're assuming that the > authoritative SIP proxy server for example.com is a different server than > the "PNA" for example.com, right? I had been thinking these were often -- > but not necessarily -- the same server. If these are the same server, then > the static registration isn't necessary, of course. If these are not the > same server, then why isn't this just transparent to everybody outside the > example.com administrative domain? If the authoritative server is the same, there is just some internal configuration so the server knows it needs to handle such-and-such event packages itself. If they are not the same, the server can be configured to route incoming SUBSCRIBE requests to the correct SIP server (the PNA). The outside world can't assume it knows how the "example.com" domain wants to handle some SIP requests to sip:alice@example.com differently from others. That's local administrative policy. If an external entity decides to send INVITEs to example.com (sip:alice@example.com), but somehow instead sends SUBSCRIBEs to pna.example.com (sip:alice@pna.example.com) that is also perfectly fine, but not as convenient for the subscriber. This is no different from XMPP routing request of a specific type from bare JID (xmpp:alice@example.com) to a specific resource (xmpp:alice@example.com/msgevents) instead of addressing that resource directly. Likewise, a web proxy or redirector can point requests for http://(www.)example.com/webmail to http://webmail.example.com, or the HTTP user agent can go there directly. hope that helps. thanks, -rohan > thanks, > Lisa _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jul 02 15:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RYD-00005w-3A; Mon, 02 Jul 2007 15:27:09 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I5RYB-00005g-Kh for notifications-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 15:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RYA-00005F-Cv for Notifications@ietf.org; Mon, 02 Jul 2007 15:27:07 -0400 Received: from an-out-0708.google.com ([209.85.132.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RY6-0006HX-3R for Notifications@ietf.org; Mon, 02 Jul 2007 15:27:06 -0400 Received: by an-out-0708.google.com with SMTP id c17so358677anc for ; Mon, 02 Jul 2007 12:27:01 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XY0klvCsEPKu0VcuK6Dn9jefggM126sFdeM39YajJKOXMbg/2xHYGpdzNCX5tfVlhh2GmDpS2oyroXix9kmIMPmwLsDbIpkqe9Ea8ownIApyI/V6685WgrIpZZEYyRRjXxVTGJbPkCISN1ydlFS+nddFd7FmlSvqXBfEKv+hc2g= 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=l+FWbDKJ4GsRK5Ee7MZvUzVjZ1NqEln4khkmGpQqpFzeNYnytWwfv6Oe0akvrLmbyM4j4lgFkQYi8fgVkRvAzrd6haZELOY6smSOYXymcoRLPfVG2DJZS++F+v+ZKE7SBfml43RWKHSby8h3LdDMaQ1GrEnP4HWk4GQeGnYehUg= Received: by 10.100.153.17 with SMTP id a17mr3907866ane.1183404420352; Mon, 02 Jul 2007 12:27:00 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Mon, 2 Jul 2007 12:27:00 -0700 (PDT) Message-ID: <953beacc0707021227q5f6509c7q94500df14c3b5a49@mail.gmail.com> Date: Mon, 2 Jul 2007 12:27:00 -0700 From: "Rohan Mahy" To: "Lisa Dusseault" Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 In-Reply-To: <20203FBC-3DC7-454B-8428-12658EEC55B3@commerce.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> <7A571611-BCEA-4826-8A32-913BBFD5923A@ekabal.com> <20203FBC-3DC7-454B-8428-12658EEC55B3@commerce.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Rohan Mahy , 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 On 7/2/07, Lisa Dusseault wrote: > On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote: > My confusion here is that the architecture I propose does not demand > interdomain aggregation. I've tried to make it more clear that the PNA is > responsible for fanout of events (aggregation of subscriptions is the > flipside of fanout of events) but I didn't require the CNA to also do so. > > This does not jive with the expansion of the CNA acronym. The "A" in CNA > stands for *Aggregator*? What is the CNA aggregating if the PNA is already > aggregating everything? > I could have used the word proxy or server and I'm not sure why I didn't. I > expect sometimes the software the CNA and the PNA are running will be just > the same, only their role will be different. So I would rather not use > "Consumer Notification Server" and "Publisher Notifications Aggregator" or > readers will think it is two specialized servers. Is "Server" better for > both? I think PNA and CNS are fine. Its also fine to point out that these are logical roles and they can be combined. > Aren't there cases where a SIP CNA will act as an aggregator and forward > events to more than one device? It's not required of the CNA, but isn't it > likely? This is a crux of the problem. I think the answer to both is a very firm NO. Why does a PNA in one domain trust the CNA in another to do aggregation on its behalf? Why is the CNA willing to take on the work of aggregating and amplifying subscriptions from another domain? How does the CNA know which subscribing identities share the same notifications and which do not, without violating the privacy of this information? Why did we draw a domain boundary in the architecture picture in the first place? These are the sort of blind trust assumptions that tend to get us into trouble. Finally, I ask what real benefit would we get from this aggregation if we did implement it? What are we trying to optimize? Certainly optimizing bandwidth between servers in two domains which are often colocated at fast peering points should be a non-goal. The number of subscribers for Alice's mailbox events is likely to be relatively small (under 10), so trying to offload onto the CNA to optimize the processing on the PNA saves very little. Indeed, the CNA needs at least one subscription to the PNA, and one subscription from the client if it plans to aggregate, while proxying a subscription results only in one subscription from the client to the PNA. If the average number of subscribing clients per mailbox is less than two, we've generated MORE state and more messaging traffic. thanks, -rohan _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Jul 20 09:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsV5-0007uN-0q; Fri, 20 Jul 2007 09:26:31 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IBsV3-0007pf-0X for notifications-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 09:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsUz-0007pX-HX for notifications@ietf.org; Fri, 20 Jul 2007 09:26:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBsUy-00071Q-SZ for notifications@ietf.org; Fri, 20 Jul 2007 09:26:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2007 06:25:52 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAJVoEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,563,1175497200"; d="scan'208"; a="505391681:sNHT1967998808" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6KDPqEW013903 for ; Fri, 20 Jul 2007 06:25:52 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l6KDPp6D012002 for ; Fri, 20 Jul 2007 13:25:51 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <550143D9-04E0-4E64-BB2E-3451E7FCA5A9@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: notifications@ietf.org From: Cullen Jennings Date: Fri, 20 Jul 2007 06:24:40 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=914; t=1184937952; x=1185801952; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Reading=20list=20for=20BOF |Sender:=20; bh=QqjvWnUF/Fv8R3z/KcyORbIrWTOwHF1pCwGlZCYzGHM=; b=VkPkQWz0b9isaxeiTuu8uIgodKYjxaQTz9P/pRXw/gpIQttyMU7UWyYDWlB5TpE5rh6H5MWl JuwIFtzJjqIHYLeZx28FqFmxDi03wlDBISKeu7SUGKuzYD6QyWSVqmey; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Notifications] Reading list for BOF 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 Notifications from Mail Stores BOF (BIFF) Time: Friday, July 27, 0900-1130 Location: Salon 2 Area Director: Chris Newman BOF Chairs: Randall Gellens & Cullen Jennings Agenda TBD Email List: notifications@ietf.org Email Archive: http://www1.ietf.org/mail-archive/web/notifications/current/ index.html Reading List Input Documents for potential WG draft-ietf-lemonade-msgevent-04 draft-dusseault-email-notif-model-00 Related Background RFC3842 (MWI Event Package for SIP) RFC2177 (IMAP4 IDLE Command) draft-mahy-sieve-notify-sip-00.txt BOF Description This BOF is on the topic of connecting email systems with existing Common Presence Protocol compliant systems such as XMPP and SIP/SIMPLE to deliver notification about events from the mail store. Draft Charter TBD _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jul 23 07:27:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICw4I-0006C6-2i; Mon, 23 Jul 2007 07:27:14 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1ICw4H-0006BZ-AR for notifications-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 07:27:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICw4G-0006BL-Vs for notifications@ietf.org; Mon, 23 Jul 2007 07:27:13 -0400 Received: from rufus.isode.com ([62.3.217.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICw4G-0001rq-Jz for notifications@ietf.org; Mon, 23 Jul 2007 07:27:12 -0400 Received: from [172.28.168.141] ((unknown) [67.97.210.2]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 23 Jul 2007 12:27:08 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <46A49EE3.7060002@isode.com> Date: Mon, 23 Jul 2007 13:28:19 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: notifications@ietf.org Subject: Re: [Notifications] Reading list for BOF References: <550143D9-04E0-4E64-BB2E-3451E7FCA5A9@cisco.com> In-Reply-To: <550143D9-04E0-4E64-BB2E-3451E7FCA5A9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Cullen Jennings wrote: > Reading List > Input Documents for potential WG > draft-ietf-lemonade-msgevent-04 > draft-dusseault-email-notif-model-00 > Related Background > RFC3842 (MWI Event Package for SIP) > RFC2177 (IMAP4 IDLE Command) (I understand that this is slightly out of scope for the BOFF) Note that draft-gulbrandsen-imap-notify-07.txt is effectively replacing RFC 2177. It has a more complete mapping of draft-ietf-lemonade-msgevent-04 to IMAP responses. > draft-mahy-sieve-notify-sip-00.txt _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jul 24 20:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUrG-0007d3-GZ; Tue, 24 Jul 2007 20:36:06 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IDUrE-0007cQ-SO for notifications-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 20:36:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUrE-0007cG-G1 for notifications@ietf.org; Tue, 24 Jul 2007 20:36:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDUrE-0002Dt-1G for notifications@ietf.org; Tue, 24 Jul 2007 20:36:04 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6P0a1V09759 for ; Wed, 25 Jul 2007 00:36:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Notifications] Reading list for BOF Date: Tue, 24 Jul 2007 20:35:54 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D10EA326F@zcarhxm0.corp.nortel.com> In-Reply-To: <550143D9-04E0-4E64-BB2E-3451E7FCA5A9@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Reading list for BOF Thread-Index: AcfK0ZrqWia4UDFDT9OexKcysb+MNADfU5nw References: <550143D9-04E0-4E64-BB2E-3451E7FCA5A9@cisco.com> From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 FYI, There are several notifications activities in the LEMONADE WG: draft-ietf-lemonade-msgevent-04.txt draft-gulbrandsen-imap-notify-07.txt draft-ietf-lemonade-notifications-04.txt=20 The first has completed WGLC, the second will go to WGLC shortly. But we are still discussing the third. It contains our architecture, server-server considerations, and an EMN/SMS example. Randy volunteered to lead a design team to conclude on what sort of 'kick notification' (as well as server-server interaction) to describe for the LEMONADE Profile bis context. And as a result, the content of the third. Our goal is to be done by the next meeting, so this work is on a different time scale than the BIFF BOF work. Cheers, Glenn. -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, July 20, 2007 9:25 AM To: notifications@ietf.org Subject: [Notifications] Reading list for BOF Notifications from Mail Stores BOF (BIFF) Time: Friday, July 27, 0900-1130 Location: Salon 2 Area Director: Chris Newman BOF Chairs: Randall Gellens & Cullen Jennings Agenda TBD Email List: notifications@ietf.org Email Archive: http://www1.ietf.org/mail-archive/web/notifications/current/ index.html Reading List Input Documents for potential WG draft-ietf-lemonade-msgevent-04 draft-dusseault-email-notif-model-00 Related Background RFC3842 (MWI Event Package for SIP) RFC2177 (IMAP4 IDLE Command) draft-mahy-sieve-notify-sip-00.txt BOF Description This BOF is on the topic of connecting email systems with existing Common Presence Protocol compliant systems such as XMPP and SIP/SIMPLE to deliver notification about events from the mail store. Draft Charter TBD _______________________________________________ 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 From notifications-bounces@ietf.org Fri Jul 27 12:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESdt-0003Mx-Ck; Fri, 27 Jul 2007 12:26:17 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IESdr-0003Mq-Pp for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 12:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESdn-0003Mh-L7 for notifications@ietf.org; Fri, 27 Jul 2007 12:26:11 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IESdn-0008Kl-74 for notifications@ietf.org; Fri, 27 Jul 2007 12:26:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6RGPp8m004183 for ; Fri, 27 Jul 2007 19:26:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 19:26:07 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 19:26:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [Notifications] Use cases Date: Fri, 27 Jul 2007 19:25:42 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Use cases Thread-Index: AcfQasbSNjoXJbKWRBaMIQ6HUXGzKQ== From: To: X-OriginalArrivalTime: 27 Jul 2007 16:26:07.0258 (UTC) FILETIME=[D5A157A0:01C7D06A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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="===============0934908047==" Errors-To: notifications-bounces@ietf.org This is a multi-part message in MIME format. --===============0934908047== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D06A.D5768E11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D06A.D5768E11 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, is there some sort of use case template available that we should use, or = is it freestyle? Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 ------_=_NextPart_001_01C7D06A.D5768E11 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Notifications] Use cases

Hello everyone,
is there some sort of use = case template available that we should use, or is it freestyle?
Thank You.

Best regards: Zolt=E1n = =D6rd=F6gh
E-mail: zoltan = dot ordogh at nokia dot com
Phone: = +358 50 386 = 0566


------_=_NextPart_001_01C7D06A.D5768E11-- --===============0934908047== 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 --===============0934908047==-- From notifications-bounces@ietf.org Fri Jul 27 14:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEUOy-0003sj-QG; Fri, 27 Jul 2007 14:19:00 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEUOx-0003ma-As for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 14:18:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEUOx-0003mS-1S for notifications@ietf.org; Fri, 27 Jul 2007 14:18:59 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEUOv-0002zn-L7 for notifications@ietf.org; Fri, 27 Jul 2007 14:18:59 -0400 Received: from [130.129.17.12] (dhcp-110c.ietf69.org [130.129.17.12]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 27 Jul 2007 19:18:52 +0100 Message-ID: <46AA4560.8040408@isode.com> Date: Fri, 27 Jul 2007 20:20:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Zoltan.Ordogh@nokia.com Subject: Re: [Notifications] Use cases References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> In-Reply-To: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Zoltan.Ordogh@nokia.com wrote: > Hello everyone, > is there some sort of use case template available that we should use, > or is it freestyle? > I think it is freestyle. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Jul 27 15:04:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV6r-0005fm-FM; Fri, 27 Jul 2007 15:04:21 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEV6p-0005fZ-H1 for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 15:04:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV6n-0005fL-Qz for notifications@ietf.org; Fri, 27 Jul 2007 15:04:17 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEV6m-0004H2-Bo for notifications@ietf.org; Fri, 27 Jul 2007 15:04:17 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6RJ3sDQ015500; Fri, 27 Jul 2007 22:04:14 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 22:03:58 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 22:03:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Notifications] Use cases Date: Fri, 27 Jul 2007 22:03:34 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DE5@esebe199.NOE.Nokia.com> In-Reply-To: <46AA4560.8040408@isode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Use cases Thread-Index: AcfQep7SxnS5HZRoSx+J0JkSWOkxuwABZEoQ References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> From: To: X-OriginalArrivalTime: 27 Jul 2007 19:03:58.0732 (UTC) FILETIME=[E31194C0:01C7D080] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Good luck to whoever volunteered to consolidate them :-) Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Alexey Melnikov [mailto:alexey.melnikov@isode.com]=20 >Sent: 27 July, 2007 22:20 >To: Ordogh Zoltan (Nokia-TP-MSW/Tampere) >Cc: notifications@ietf.org >Subject: Re: [Notifications] Use cases > >Zoltan.Ordogh@nokia.com wrote: > >> Hello everyone, >> is there some sort of use case template available that we=20 >should use,=20 >> or is it freestyle? >> >I think it is freestyle. > > _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Jul 27 15:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV97-0007Ec-Uj; Fri, 27 Jul 2007 15:06:41 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEV96-0007EV-BW for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 15:06:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEV96-0007EN-1T for notifications@ietf.org; Fri, 27 Jul 2007 15:06:40 -0400 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEV95-0004eF-KT for notifications@ietf.org; Fri, 27 Jul 2007 15:06:39 -0400 Received: from [172.28.169.71] ([67.97.210.2]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6RJ6EId006372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 12:06:15 -0700 Message-ID: <46AA4241.1060104@dcrocker.net> Date: Fri, 27 Jul 2007 14:06:41 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 CC: notifications@ietf.org Subject: Re: [Notifications] Use cases References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> In-Reply-To: <46AA4560.8040408@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 1.6 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: notifications-bounces@ietf.org Alexey Melnikov wrote: > Zoltan.Ordogh@nokia.com wrote: > >> Hello everyone, >> is there some sort of use case template available that we should use, >> or is it freestyle? >> > I think it is freestyle. Yeah, but as long as the question got asked, here are the kinds of things I try to answer with a use case: Scenario: What is it that someone wants to do, that they cannot current do. This is a non-technical, user-level description. Probably no acronyms and certainly no implementation choices. (User-level can refer to end-users, sysadmin, or anyone else that is the consumer of the service.) Problem: What prevents using existing tools for accomplishing this? Market: Who needs this and should we believe they need it immediately? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Jul 27 15:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVxq-0003cs-2i; Fri, 27 Jul 2007 15:59:06 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEVxo-0003ck-Im for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 15:59:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEVxo-0003cP-91 for notifications@ietf.org; Fri, 27 Jul 2007 15:59:04 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEVxn-0005Mq-Fh for notifications@ietf.org; Fri, 27 Jul 2007 15:59:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6RJwriI011698; Fri, 27 Jul 2007 22:58:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 22:58:53 +0300 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 22:58:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Notifications] Use cases Date: Fri, 27 Jul 2007 22:58:29 +0300 Message-ID: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DF3@esebe199.NOE.Nokia.com> In-Reply-To: <46AA4241.1060104@dcrocker.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Use cases Thread-Index: AcfQgWMK+d6p5l07SCGCsVyrbDWxWgAA0lkA References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com><46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> From: To: X-OriginalArrivalTime: 27 Jul 2007 19:58:53.0114 (UTC) FILETIME=[8EAC61A0:01C7D088] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Oh, so it would be good to agree beforehand because I had completely = different ideas. Like: Scenario Joe wants to turn on his coffee machine in the morning so that when he = wakes up, the coffee is already waiting... Actors: IMAP Server, Notification Server, Client (Joe's coffee machine), Joe Pre-conditions 1. Joe goes to sleep but before doing so, He schedules a future mail = delivery for Himself, 0600 in the morning (subject: coffee "1 big decaf = +milk"; no body). 2. Client (Joe' coffee machine) is subscribed to Joe's mail events, = particularly to the an event when an email arrives from Himself. 3. Client is configured to ingore all other mails that those from Joe = with "coffee" in the subject line, and the hardware configuraton is = satisfactory (has coffee, electricity, water, cups, etc). 4. The Notification Server supports sender and subject fields. 5. IMAP Server has AfterBLAST support. Flow: 1. Future delivery is triggered at 0600 in the morning, therefore a new = mail arrive to Joe from Himself. 2. IMAP Server BLASTs some info to the Notification Server. 3. Notification Server informs the Client. 4. Client validates conditions and prepares Joe's coffee, as instructed = by the subject field -> a big decaf coffee with milk. 5. As instructed by Joe's SIEVE script (that is triggered AfterBLAST), = the unnecessary email is removed from the mailbox after the information = was BLASTED to the Notification Server. Alternate flow: - two coffees, one for the wife as well, using the same Client - using = the same event. - two coffees, one for the wife as well, using the same Client - using = different events. Expected results: - the coffee conforms to the requested parameters. - Joe is a happy IMAPCoffee customer enjoying the benefits of his = well-spent investment. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 =20 >-----Original Message----- >From: ext Dave Crocker [mailto:dhc@dcrocker.net]=20 >Sent: 27 July, 2007 22:07 >Cc: notifications@ietf.org >Subject: Re: [Notifications] Use cases > > > >Alexey Melnikov wrote: >> Zoltan.Ordogh@nokia.com wrote: >>=20 >>> Hello everyone, >>> is there some sort of use case template available that we=20 >should use,=20 >>> or is it freestyle? >>> >> I think it is freestyle. > > >Yeah, but as long as the question got asked, here are the=20 >kinds of things I try to answer with a use case: > > >Scenario: > > What is it that someone wants to do, that they cannot=20 >current do. This is=20 >a non-technical, user-level description. Probably no acronyms=20 >and certainly=20 >no implementation choices. (User-level can refer to=20 >end-users, sysadmin, or=20 >anyone else that is the consumer of the service.) > > >Problem: > > What prevents using existing tools for accomplishing this? > > >Market: > > Who needs this and should we believe they need it immediately? > > >d/ > >--=20 > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > >_______________________________________________ >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 From notifications-bounces@ietf.org Fri Jul 27 18:17:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY7p-00014X-NM; Fri, 27 Jul 2007 18:17:33 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEY7n-00014H-N7 for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 18:17:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY7n-000148-DP for notifications@ietf.org; Fri, 27 Jul 2007 18:17:31 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEY7n-0000xr-2T for notifications@ietf.org; Fri, 27 Jul 2007 18:17:31 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2007 15:17:30 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALsLqkarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,590,1175497200"; d="scan'208"; a="168532162:sNHT40530438" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6RMHUgw007821 for ; Fri, 27 Jul 2007 15:17:30 -0700 Received: from [130.129.21.174] (rtp-vpn3-416.cisco.com [10.82.217.162]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6RMGdTf018889 for ; Fri, 27 Jul 2007 22:17:29 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <0F4D841F-40E2-464E-AF1A-986012C41FCE@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: notifications@ietf.org From: Cullen Jennings Date: Fri, 27 Jul 2007 17:17:26 -0500 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=918; t=1185574650; x=1186438650; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Enterprise=20MWI=20Use=20Case |Sender:=20; bh=+LaQV+C3JuvGqDxOgVFYX2a/sow8YJrClGazzeGlBWU=; b=RYT9Uu0RcryCxJeCKUAymb8VnsSaVNIBALILBjbJDhvetYZOMROEQnjOUFkfiUNsBEeBGtku 4EkzHV+IIe8RSQZ/myXjv6JfbnhNl7N6ZAfS1+dzBS9ztiOUtzuU+MML; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Notifications] Enterprise MWI Use Case 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 Phase 1: Enterprise phones have a little red light on them. This light should be on if, and only if, the the email store as any unseen message that contain voicemails. I don't really know the precise term for "unseen" or "voicemail" mean in this context so hopefully someone can provide the right term. On average, this light changes state less than a 6 times per day. A large system would have less than 100,000 phones receiving notifications. The network environment is typically 100Mbps although sometimes remote offices with a less than 500 phones will be on a slower WAN link. When the state on the email store changes, the red light needs to change in less than 10 seconds and changing in under 2 seconds is desirable. If a phone is power cycled, the state of the red light after the power cycle needs to be correct and can not wait for the next time the state changes. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Fri Jul 27 18:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY9w-0002N4-K3; Fri, 27 Jul 2007 18:19:44 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IEY9u-0002My-VT for notifications-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 18:19:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEY9u-0002Ml-J1 for notifications@ietf.org; Fri, 27 Jul 2007 18:19:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEY9t-0000pa-9m for notifications@ietf.org; Fri, 27 Jul 2007 18:19:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2007 18:19:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADMMqkZAZnme/2dsb2JhbACwQQ X-IronPort-AV: i="4.16,590,1175486400"; d="scan'208"; a="66385905:sNHT38372708" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6RMJeLh001175; Fri, 27 Jul 2007 18:19:40 -0400 Received: from [130.129.21.174] (rtp-vpn3-416.cisco.com [10.82.217.162]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6RMJZWI025105; Fri, 27 Jul 2007 22:19:40 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Fri, 27 Jul 2007 17:19:28 -0500 To: notifications@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11418; t=1185574780; x=1186438780; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Draft=20Minutes=20from=20IETF=2069=20meeting |Sender:=20 |To:=20notifications@ietf.org; bh=Qut16qyAsccywwCJxb6VLmQSjuJ2i2g5fP3C3NcGUjQ=; b=c/W1iLhrU0mnydP22wQHtI0hd2zFfM+9H/6cxtMsxB3dcyqf9eqGNNpurPH5fC47gs8H8tF0 zD69zyYYh11TklKbpQYe1SR9tbZLR+Zmk+toRKhipLA8Sk7b1VdEA44x; Authentication-Results: rtp-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: Randall Gellens Subject: [Notifications] Draft Minutes from IETF 69 meeting 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 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@ietf.org" will be used for further work by this group. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Mon Jul 30 13:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYug-00040i-Lr; Mon, 30 Jul 2007 13:20:10 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFYug-0003zU-06 for notifications-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYuf-0003yj-Kg for notifications@ietf.org; Mon, 30 Jul 2007 13:20:09 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYuV-0003Wc-8d for notifications@ietf.org; Mon, 30 Jul 2007 13:20:09 -0400 Received: by an-out-0708.google.com with SMTP id c17so317849anc for ; Mon, 30 Jul 2007 10:19:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EGV6D7cARBUChv72GIPWVXpzk0X961Bxg4pnzT25pm2AdefkTRMUo1IyPryWibU39OkXbOXVtPI0QpJULYMZUbkm3U2oGHbbXqQL9bPnyCjjdhIpLogcWgPyzKMajX+BZxJY41S6U7JPszRfY4tlS9lmdfLlC20adMzKvS2CN7k= 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=et8eGcTYuGZANGa1cT3ST2D7u1N7X9xutoDj9MsA0vUOjQa1xJGT8zdhCUbZSasF/8c13Ju6ybc2S+q0CsuQ4PC9e7DuIKzYqfZHyWfJbDwxn3QsnToPljZKbsUTYeENo8CXLhEzQAfOMZOIsooW4tppKeiHlQYDFY7ub0mSoa8= Received: by 10.100.91.6 with SMTP id o6mr4753358anb.1185815998135; Mon, 30 Jul 2007 10:19:58 -0700 (PDT) Received: by 10.100.124.4 with HTTP; Mon, 30 Jul 2007 10:19:57 -0700 (PDT) Message-ID: <953beacc0707301019l6170c84frff03cd14c8b39580@mail.gmail.com> Date: Mon, 30 Jul 2007 10:19:57 -0700 From: "Rohan Mahy" To: notifications@ietf.org Subject: Re: [Notifications] Use cases In-Reply-To: <46AA4241.1060104@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4C38DC11F6B4FF4FAEA73E30DB5AA157D77DC3@esebe199.NOE.Nokia.com> <46AA4560.8040408@isode.com> <46AA4241.1060104@dcrocker.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Rohan Mahy 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 Scenario: A widget on my cell phone that correlates all package tracking emails from Federal Express. It is interested in the Subject and To header of all emails sent From tracker.fedex.com. When it gets a new notification, it parses the tracking number from the Subject and does an HTTP fetch to get the current status of the package. It can then beep or chime or prompt you to send an email or a phone call or SMS when various things happen (package picked up, package delivered, package delayed, package cleared customs). This model would apply nicely to other widgets for package tracking, flight status, sales order notifications, and stock trade confirmations. Problem: The cell phone does not want to poll for new messages (for example using IMAP) because this would negatively affect battery life. Better to use an existing open TCP connection already used by SIP or XMPP to receive these async notifications. Also, the phone is only interested in a filtered view of notifications. There are ways of doing this today in email, but just forwarding all your email to an IM gateway using a static filter isn't sufficient. If the phone has multiple widgets, these filters my need to be somewhat dynamic. Market: Widgets like this are popping up left and right, but they use HTTP polling. The market would like these apps and decent battery consumption too. thanks, -rohan _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jul 31 06:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpAv-0002Mq-7U; Tue, 31 Jul 2007 06:42:01 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFpAt-0002Fy-Pk for notifications-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 06:42:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpAq-00020m-3Z for notifications@ietf.org; Tue, 31 Jul 2007 06:41:56 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFpAp-00031m-Gl for notifications@ietf.org; Tue, 31 Jul 2007 06:41:56 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VAfqXx008841; Tue, 31 Jul 2007 03:41:52 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VAfofc000741; Tue, 31 Jul 2007 03:41:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Notifications] Use cases Date: Tue, 31 Jul 2007 03:41:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Use cases Thread-Index: AcfSzehpsShTA9FmTUq3XvHfHPsxNgAkX2mB From: "Eric Burger" To: , x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External 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 First scenario: is that not what sieve does today? Second scenario: once you assume a long-lived TCP connection, the IMAP connection is free. I would also offer the IMAP NOTIFY message can be an order of magnitude smaller than a fully-routed SIP message, which would save bandwidth. -- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see for what lemonade is. -----Original Message----- From: Rohan Mahy To: notifications@ietf.org CC: Rohan Mahy Sent: Mon Jul 30 10:19:57 2007 Subject: Re: [Notifications] Use cases Scenario: A widget on my cell phone that correlates all package tracking emails from Federal Express. It is interested in the Subject and To header of all emails sent From tracker.fedex.com. When it gets a new notification, it parses the tracking number from the Subject and does an HTTP fetch to get the current status of the package. It can then beep or chime or prompt you to send an email or a phone call or SMS when various things happen (package picked up, package delivered, package delayed, package cleared customs). This model would apply nicely to other widgets for package tracking, flight status, sales order notifications, and stock trade confirmations. Problem: The cell phone does not want to poll for new messages (for example using IMAP) because this would negatively affect battery life. Better to use an existing open TCP connection already used by SIP or XMPP to receive these async notifications. Also, the phone is only interested in a filtered view of notifications. There are ways of doing this today in email, but just forwarding all your email to an IM gateway using a static filter isn't sufficient. If the phone has multiple widgets, these filters my need to be somewhat dynamic. Market: Widgets like this are popping up left and right, but they use HTTP polling. The market would like these apps and decent battery consumption too. thanks, -rohan _______________________________________________ Notifications mailing list Notifications@ietf.org 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 Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jul 31 07:12:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpdw-0000pi-LM; Tue, 31 Jul 2007 07:12:00 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFpdv-0000pa-5T for notifications-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 07:11:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpdu-0000pQ-R7 for notifications@ietf.org; Tue, 31 Jul 2007 07:11:58 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFpdu-0004Bn-An for notifications@ietf.org; Tue, 31 Jul 2007 07:11:58 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VBBuPN025455; Tue, 31 Jul 2007 04:11:56 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VBBIcJ021836; Tue, 31 Jul 2007 04:11:19 -0700 Received: from 172.24.28.86 ([172.24.28.86]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Jul 2007 11:11:54 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 30 Jul 2007 07:44:46 -0500 Subject: Re: [Notifications] Enterprise MWI Use Case From: Eric Burger To: Cullen Jennings , Message-ID: Thread-Topic: [Notifications] Enterprise MWI Use Case Thread-Index: AcfQm/hBZdoTqVmnRGWHBf7SuUpgqQCC3BdY In-Reply-To: <0F4D841F-40E2-464E-AF1A-986012C41FCE@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 help on the what is "voicemail": see RFC 3458. On 7/27/07 5:17 PM, "Cullen Jennings" wrote: > > > Phase 1: > > Enterprise phones have a little red light on them. This light should > be on if, and only if, the the email store as any unseen message that > contain voicemails. I don't really know the precise term for "unseen" > or "voicemail" mean in this context so hopefully someone can provide > the right term. On average, this light changes state less than a 6 > times per day. A large system would have less than 100,000 phones > receiving notifications. The network environment is typically 100Mbps > although sometimes remote offices with a less than 500 phones will be > on a slower WAN link. When the state on the email store changes, the > red light needs to change in less than 10 seconds and changing in > under 2 seconds is desirable. If a phone is power cycled, the state > of the red light after the power cycle needs to be correct and can > not wait for the next time the state changes. > > > > > > > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > 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 Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jul 31 07:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpdy-0000qf-OZ; Tue, 31 Jul 2007 07:12:02 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFpdx-0000qZ-No for notifications-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 07:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpdx-0000qR-ED for notifications@ietf.org; Tue, 31 Jul 2007 07:12:01 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFpdv-0002Zx-RK for notifications@ietf.org; Tue, 31 Jul 2007 07:12:01 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VBBvLA025462; Tue, 31 Jul 2007 04:11:57 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id l6VBBIcL021836; Tue, 31 Jul 2007 04:11:20 -0700 Received: from 172.24.28.86 ([172.24.28.86]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Tue, 31 Jul 2007 11:11:55 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 30 Jul 2007 07:46:38 -0500 Subject: Re: [Notifications] Draft Minutes from IETF 69 meeting From: Eric Burger To: Cullen Jennings , Message-ID: Thread-Topic: [Notifications] Draft Minutes from IETF 69 meeting Thread-Index: AcfQnEXMlPuv+bAfR56WUiEpF7PYpACC2WWh In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 1.8 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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 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" 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 "notifications@ietf.org" will be used for further > work by this group. > > > _______________________________________________ > Notifications mailing list > Notifications@ietf.org > 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 Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications From notifications-bounces@ietf.org Tue Jul 31 09:28:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFrmJ-0000gi-7S; Tue, 31 Jul 2007 09:28:47 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1IFrmH-0000gb-RJ for notifications-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 09:28:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFrmH-0000gT-Gb for notifications@ietf.org; Tue, 31 Jul 2007 09:28:45 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFrmH-0001cG-6Y for notifications@ietf.org; Tue, 31 Jul 2007 09:28:45 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-12.tower-121.messagelabs.com!1185888523!19214552!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 17028 invoked from network); 31 Jul 2007 13:28:44 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 31 Jul 2007 13:28:44 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6VDShhe032014 for ; Tue, 31 Jul 2007 09:28:43 -0400 Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6VDSWQc031912 for ; Tue, 31 Jul 2007 09:28:36 -0400 Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6VDSVsi025449 for ; Tue, 31 Jul 2007 09:28:31 -0400 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l6VDSIlM025159 for ; Tue, 31 Jul 2007 09:28:26 -0400 Received: from [135.210.128.177] (unknown[135.210.128.177](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070731132817gw10010gnqe> (Authid: tony); Tue, 31 Jul 2007 13:28:18 +0000 Message-ID: <46AF3932.5030505@att.com> Date: Tue, 31 Jul 2007 09:29:22 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: notifications@ietf.org Subject: Re: [Notifications] Use cases References: In-Reply-To: X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 As Randy reminded me at the meeting :-), after we get a bunch of potential use cases, each of them needs to be passed through a filter of "should this be better done by a good sieve implementation that includes the notification extension". But brainstorm first and keep the ideas flowing, *before* running them through the filter. Tony Hansen tony@att.com Eric Burger wrote: > First scenario: is that not what sieve does today? > > Second scenario: once you assume a long-lived TCP connection, the > IMAP connection is free. I would also offer the IMAP NOTIFY message > can be an order of magnitude smaller than a fully-routed SIP message, > which would save bandwidth. _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications