From notifications-bounces@ietf.org Tue Apr 10 15:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbM4w-0007C7-VO; Tue, 10 Apr 2007 15:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbM4w-0007BV-0x for notifications@ietf.org; Tue, 10 Apr 2007 15:32:34 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbM4r-0003Vv-Kd for notifications@ietf.org; Tue, 10 Apr 2007 15:32:34 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AJWNQF028565; Tue, 10 Apr 2007 12:32:23 -0700 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3AJWHSE009272; Tue, 10 Apr 2007 12:32:22 -0700 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: 7bit Subject: RE: [Notifications] Notifications Pictures Date: Tue, 10 Apr 2007 12:32:22 -0700 Message-ID: In-Reply-To: <4607F914.3030409@jabber.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Notifications] Notifications Pictures Thread-Index: AcdvxoUg1WRwX6ygQi+W2lTlXZ++ogLwFr/g References: <4607F914.3030409@jabber.org> From: "Eric Burger" To: "Peter Saint-Andre" x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 The reason for the token is we cannot require an association between the source of the notification (possibly a random enterprise) and the notification network (possibly a random wireless carrier). Things get much easier if we assume prior registration. We discussed this scenario, and felt it was not realistic. -----Original Message----- From: Peter Saint-Andre [mailto:stpeter@jabber.org] Sent: Monday, March 26, 2007 12:47 PM To: Randall Gellens Cc: notifications@ietf.org Subject: Re: [Notifications] Notifications Pictures Randall Gellens wrote: > In order to allow the notifications server to be in a different > administrative domain from the application servers (such as being in a > mobile carrier's network), the client obtains a token from the > notification server, passes it to the application server, which > includes it in (or uses it to sign) notifications. This allows the > notification server to not accept notifications that aren't sent on > behalf of its users, and possibly to associate a notification with the > user's device. I don't see why the token is necessary -- couldn't the notification server require prior registration before allowing the client to publish notifications? If you have stable identities, then registration seems sufficient. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml 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 Apr 10 21:51: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 1HbRz2-00069j-6Y; Tue, 10 Apr 2007 21:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbRyz-00069Q-O1 for notifications@ietf.org; Tue, 10 Apr 2007 21:50:49 -0400 Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbRyu-0004mL-Pu for notifications@ietf.org; Tue, 10 Apr 2007 21:50:49 -0400 Received: (snipe 24593 invoked by uid 0); 11 Apr 2007 10:51:13 +0900 Received: from newcat@icu.ac.kr with Spamsniper 2.96.00 (Processed in 0.867101 secs); Received: from unknown (HELO ?210.107.136.145?) (Z???own@210.107.136.145) by unknown with SMTP; 11 Apr 2007 10:51:12 +0900 X-SNIPER-SENDERIP: 210.107.136.145 X-SNIPER-MAILFROM: newcat@icu.ac.kr X-SNIPER-RCPTTO: rg+ietf@qualcomm.com, notifications@ietf.org, yangwooko@gmail.com Message-ID: <461C3EE6.7040500@icu.ac.kr> Date: Wed, 11 Apr 2007 10:50:30 +0900 From: Yangwoo Ko User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Randall Gellens Subject: Re: [Notifications] Notifications Pictures References: In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Probably I am completely out of context and hence please correct me. (1) Scalability If a notification should be delivered to many clients, then it should contain as many tokens or it should be signed by multiple tokens (I don't know whether we have a handy algorithm for this.). (2) Tri-party negotiation I feel uncomfortable with the fact that a token is issued by one domain and used by the other domain. If there is any independent version up that results in new format of tokens in either domain, then is this still working? How to generate a proper format of token from an interaction only between a client and a notification server without involvement of application server, which will actually use the token. Regards Randall Gellens wrote: > A few of us met this afternoon and drew these pictures, which are > attached. The one called "notifications.pdf" attempts to show how IMAP > out-of-band notifications fits into a generic notifications model. In > this model, notifications are pushed from various application servers, > including IMAP, to a notifications server, using a standardized > server-to-server notifications protocol such as XMPP or SIP. As an > optional prior step, application clients can configure event generation > criteria. In order to allow the notifications server to be in a > different administrative domain from the application servers (such as > being in a mobile carrier's network), the client obtains a token from > the notification server, passes it to the application server, which > includes it in (or uses it to sign) notifications. This allows the > notification server to not accept notifications that aren't sent on > behalf of its users, and possibly to associate a notification with the > user's device. > > A more short-term solution to IMAP out-of-band notifications is to > deploy an extra box in front of the IMAP server which uses IMAP NOTIFY > to aggregate notifications, and sends those to a notification server, > which further filters. This is shown in the picture called > "notifications-short-term.pdf". > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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