Subject: RE: [Notifications] Notifications Pictures

From: "Eric Burger" <[email-masked]>
Date: Tue, 10 Apr 2007 12:32:22 -0700

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:[email-masked]] 
Sent: Monday, March 26, 2007 12:47 PM
To: Randall Gellens
Cc: [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 11 Apr 2007 10:50:30 +0900

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 
> 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".
> 
> 
> ------------------------------------------------------------------------
>