From notifications-bounces@ietf.org Tue Jun 19 14:40: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 1I0icZ-0004xD-2l; Tue, 19 Jun 2007 14:40:07 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I0icX-0004vv-2w for notifications-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 14:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0icT-0004vn-PF for Notifications@ietf.org; Tue, 19 Jun 2007 14:40:01 -0400 Received: from an-out-0708.google.com ([209.85.132.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0icQ-0002oT-32 for Notifications@ietf.org; Tue, 19 Jun 2007 14:40:01 -0400 Received: by an-out-0708.google.com with SMTP id c17so466138anc for ; Tue, 19 Jun 2007 11:39:57 -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:mime-version:content-type:content-transfer-encoding:content-disposition; b=mXrbYSVxyEhs06R8O36qGkWpmHOTdg6sSHXruGonQCfmTA8eP+soTVFeb2aa53y/Dy6VruZPMil1o8T6NYsZOd0HFQqjrnt9/X1BpfSgWEv2wkiElQsMQhJpeN30bbRAmIQea7QcOOkj4wkdcgP2UHB0E/DLJcB8DEYZ3dI2nNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=beO0OHLKOIS0zmx9CPRrbQp5IgAjw3/BHNAfRqjGXNqibnrk0MHSIbEU9xmrEyl8ARxt8oPnPT3XzWW08LVmj3f66tv7I3ZW4SRynoRmPucD5JuhrfBSXrmyG0b+7PYvGK/M34N3lT3ll2T+NlkPv28OF/nXkLALoBYBxH11tL8= Received: by 10.100.119.14 with SMTP id r14mr4653217anc.1182278397694; Tue, 19 Jun 2007 11:39:57 -0700 (PDT) Received: by 10.100.153.16 with HTTP; Tue, 19 Jun 2007 11:39:57 -0700 (PDT) Message-ID: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> Date: Tue, 19 Jun 2007 11:39:57 -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: 73734d43604d52d23b3eba644a169745 Cc: Rohan Mahy , Lisa Dusseault Subject: [Notifications] comments on draft-dusseault-email-notif-model-00 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, Attached are some comments after my read of draft-dusseault-email-notif-model-00. Overall I think the model is very clear and useful, except for the statements relegating sieve notifications to unsolicited status. thanks, -rohan Sect 2.1 "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 is clearly not true. It is possible for sieve events to be in the context of a subscription, as in my SIP notification draft [1] (see more comments on Sect 6). 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. 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. 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. 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. Sect 3.6 on Reliability: heartbeats imply a timer on the order of handfuls of seconds. this is widely seen as "a bad thing" for battery operated devices. I think it would be useful to mention "fast" heartbeats as a good option for non-battery operated devices. For battery-operated devices or devices with intermittent network connectivity, explicit synchronization stamps are an excellent approach. 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. 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. [1] 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 Sat Jun 30 22:12:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ovg-00036u-25; Sat, 30 Jun 2007 22:12:48 -0400 Received: from notifications by megatron.ietf.org with local (Exim 4.43) id 1I4O6b-0007wL-Ez for notifications-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 17:34:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4O6b-0007w9-3Y for Notifications@ietf.org; Fri, 29 Jun 2007 17:34:17 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4O6a-0000I5-Mi for Notifications@ietf.org; Fri, 29 Jun 2007 17:34:17 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id DB54C1AA6; Fri, 29 Jun 2007 21:33:59 +0000 (GMT) Received: from GW2.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID859LFCVIa0487Xo1; Fri, 29 Jun 2007 21:33:59 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW2.EXCHPROD.USA.NET X-USANET-MsgId: XID859LFCVIa0487Xo1 Received: from [192.168.1.100] ([154.5.206.251]) by GW2.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 15:32:18 -0600 In-Reply-To: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> References: <953beacc0706191139l74085095p8ea859631f8fa52@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5F53B1C8-3E90-4E2F-BD40-1B7FF6C9B5B2@commerce.net> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Notifications] comments on draft-dusseault-email-notif-model-00 Date: Fri, 29 Jun 2007 14:33:55 -0700 To: Rohan Mahy X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Jun 2007 21:32:18.0637 (UTC) FILETIME=[F8424FD0:01C7BA94] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Sat, 30 Jun 2007 22:12:47 -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 Rohan, I'm working through your comments and they're definitely going to help do a much better 2nd rev. 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. 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. 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? > 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? I know that RFC3841 is Caller Preferences for SIP, but how would that be used or what problems would it solve here? > 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. > > > 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. > > 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. Thanks, Lisa _______________________________________________ Notifications mailing list Notifications@ietf.org https://www1.ietf.org/mailman/listinfo/notifications