From notifications-bounces@ietf.org Fri Feb 09 14:12:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFbAq-0006cZ-Mg; Fri, 09 Feb 2007 14:12:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFbAp-0006cU-Ph for notifications@ietf.org; Fri, 09 Feb 2007 14:12:43 -0500 Received: from usremg02.bea.com ([66.248.192.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFbAp-00070q-5E for notifications@ietf.org; Fri, 09 Feb 2007 14:12:43 -0500 Received: from usremr02.bea.com (mailrelay.bea.com [10.160.29.92]) by usremg02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l19JCfFV032743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 Feb 2007 11:12:41 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by usremr02.bea.com (Switch-3.2.2/Switch-3.2.2) with ESMTP id l19JCSu5023355; Fri, 9 Feb 2007 11:12:40 -0800 Received: from 172.24.30.126 ([172.24.30.126]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Feb 2007 19:12:35 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 09 Feb 2007 08:12:34 -0600 Subject: Re: [Notifications] Setting up email event streams From: Eric Burger To: Lisa Dusseault , Message Notifications interest group discussion list Message-ID: Thread-Topic: [Notifications] Setting up email event streams Thread-Index: AcdMZRt+WgB3iLhYEdutlQAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.1.2.131432 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 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 would offer Model B, the user contacts the server directly and provisions it, is a way to go for now. First, it is very simple - we do not need to build a protocol today. Second, it meets the needs of lemonade. Third, if the market / researchers / industry figures out how to provision notification filters "in band," (Model A), then it is instantly backwards-compatible with Model B. We can always kick-off an IRTF WG on figuring out how Model A would work. On 1/15/07 3:16 PM, "Lisa Dusseault" wrote: > I've been meaning to send this out more broadly after a bit of private > comment: two quite different models for setting up event streams based on > what's easier to authenticate -- the event stream "owner" (in this case t= he > mailbox owner) or the stream recipient.=A0 I hope it helps compare differ= ent > approaches. >=20 > Lisa >=20 > --- >=20 > The goal is to start (and stop) events flowing from an event source (in o= ur > case, an email server) to the event sink, frequently using a system with = an > explicit event relay. =A0 Because there are often three parties required = in an > event flow , we have to pick some way for the three parties to coordinate. >=20 > The three parties are the event source (an email server), the event sink = (a > client, perhaps not an email client)=A0 and an event relay.=A0 The event = relay has > many users thus it has addresses for each user and possibly also addresse= s for > devices/clients.=A0 Two kinds of application-layer explicit event relays = are > starting to be common: XMPP and SIP.=A0 For the purposes of considering a= n event > feed setup model, we do not want to be concerned about the mostly orthogo= nal > issue of what protocol to use to talk to event relay.=A0 So for now we as= sume > that event relays have all features common to XMPP and SIP (addresses, pu= b/sub > features, event stream aggregation). >=20 > Choosing between two event stream setup models requires assumptions about > - what kind of authorization is easier or more important to provide > - whether there are a lot of different event sink addressess > - whether direct access to the event source is always/usually available (= can > be affected by whether the event source is publicly available) > - whether event flows stop and start frequently, or can simply be turned = on > for a very long term >=20 > MODEL A.=A0 SUBSCRIBE Chain >=20 > A-1 Description >=20 > In this model, when a user decides to get an email event flow to a partic= ular > device or piece of software, the user typically works with the event sink > interface to indicate where to get the events from.=A0 Then a SUBSCRIBE m= essage > of some kind gets generated by the event sink, sent to the event relay an= d is > handled by the event source. >=20 > A-2 Authorization issue >=20 > The authorization problem here is to determine if the address that the > SUBSCRIBE message comes from is permitted to receive these events.=A0 In = the > case of a publicly-subscribable resource this problem disappears.=A0 In m= any > email use cases, only a small number of event sink addresses will be > authorized to receive event notifications -- perhaps the event source (the > email server) can simply be configured with a short allowed list of event > recipients that doesn't change often (e.g. my personal IM address, my work > address, and the one used by my phone provided by my phone service provid= er). >=20 > Some SUBSCRIBE systems have the ability to provide a PENDING response to a > subscription.=A0 This is used when an out-of-band mechanism is initiated = to > authorize the subscribing address.=A0 In an email event source use case, = one > obvious out-of-band mechanism is for the email server to create an email = with > a link saying "Click here to authorize this subscription". >=20 > It's also possible to use a mechanism like URLAUTH to prove authorization= -- > in this approach, the subscriber provides a URL that has a secret token i= n it > authorizing the subscription.=A0 It's possible that this would authorize = the > subscribing address for future subscriptions as well, or only for a limit= ed > period. >=20 > A-3 Drawbacks: > =A0=A0 a)=A0 Only some notification protocols support SUBSCRIBE semantics. >=20 > =A0=A0 b)=A0 Complicated filters and event types (to support use cases li= ke "Alert > me on event type 'email arrives' if it is from my boss, has my full email > address or the address of the developer list on the to line, and the subj= ect > does not begin with 'FUNNY'..." )=A0 might need a little extra work.=A0 B= oth SIP > and XMPP subscriptions can be extended in such a way that existing > notification relays would pass on a filter specification in whatever > language/format most appropriate for email.=A0 It might even be possible = to send > SIEVE conditionals in the body of the SUBSCRIBE message.=A0 XMPP has > notification nodes in XEP-0060 and notification filters in XEP-0163. >=20 > A-4 Advantages > =A0=A0 b) Allows for frequent starting and stopping of subscriptions, pos= sibly an > efficiency/scaling concern >=20 >=20 > MODEL B. Sender RULES >=20 > B-1 Description >=20 > In this model, the user typically works with the event source in order to > configure it to send events to a given set of addresses.=A0 For example, = the > user might have access to a Web interface to an email server where it can= say > "Send new message notifications to xmpp://lisa@psg.com " > or someday use MANAGESIEVE. >=20 > B-2 Authorization issue >=20 > The authorization problem here is to determine if the user creating the > sending rule is authorized to send an event stream to the receiving addre= ss.=A0 > If anybody can send to the receiving address (e.g. email) then it's publi= cly > addressable and the problem disappears.=A0 Many kinds of addresses are pu= blicly > addressable and use whitelisting together with asking permission ("do you= wish > to allow messages from this source in the future"). >=20 > B-3 Drawbacks: > =A0=A0 a) Only some event sources support RULE systems.=A0 We are buildin= g SIEVE for > email clients and servers but it may be harder to generalize this beyond = email > clients and servers.=A0 Even sticking strictly the proposed scope of email > server sources, we have to consider whether a client such as a calendar c= lient > (subscribing for IMIP messages) or a time-management dashboard (subscribe= s to > "unread" counts but doesn't otherwise read email) are going to be able to > implement SIEVE, authenticate to mail servers etc. >=20 > =A0=A0 b) If sender rules are setup through Web interfaces, users are def= initely > not going to turn them on and off frequently. >=20 > =A0=A0 c) Failure feedback: how does the event source let the user know t= hat some > address keeps bouncing? > =A0=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 Fri Feb 23 17:27:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKisw-0002c3-Be; Fri, 23 Feb 2007 17:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKist-0002bn-Bd; Fri, 23 Feb 2007 17:27:23 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKisr-0008NZ-Tb; Fri, 23 Feb 2007 17:27:23 -0500 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 l1NMR7s14893; Fri, 23 Feb 2007 17:27:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Feb 2007 17:26:44 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0E88A7CA@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notes from the Jan 25th jabber chat on notifications Thread-Index: AcdXmbLw1QT+xFbaT6SO+bULR2p0/A== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: lemonade@ietf.org Subject: [Notifications] Notes from the Jan 25th jabber chat on notifications X-BeenThere: notifications@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Message Notifications interest group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1981068551==" Errors-To: notifications-bounces@ietf.org This is a multi-part message in MIME format. --===============1981068551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75799.B38A86E7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75799.B38A86E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable LEMONADE Notifications chat January 25, 2007 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Full log: http://www.ietf.org/meetings/ietf-logs/lemonade/2007-01-25.html Online personalities: bernard.desruisseaux=20 eburger - Eric Burger alexeymelnikov Glenn Parsons Dave Cridland Ams - Abhijit Menon-Sen Lisa - Lisa Dusseault Arnt - Arnt Gulbrandsen Rohan - Rohan Mahy Discussion ------------- Current documents: draft-newman-lemonade-msgevent-00 draft-ietf-lemonade-notifications-03 OMA MEM REQ & AD draft-mahy-sieve-notify-sip-00 Types of notifications * out of band * real time * various transport mechanisms - SIEVE, IMAP events, ... Types of out of band notifications * new message notification * new message notification with different degrees of details * mailbox state change notification * file updated Things to decide about notifications: * how to send=20 * who to send to * what to send Concern about clients avoiding sync really being a subvertive IMAPv5 Concern on frequency of SIEVE messages for notifications has been alleviated, however there is still an issue on how to deal with multiple devices. SIEVE scripts (for mobile devices) will tend to be semi-permanent, there was a concern noted that designing for this might prohibit dynamic scripts. SIEVE is obvious for 'user oriented' notifications, but it is overkill for MWI. MWI is already defined using SIP (RFC 3842) but is that necessary for email? Notifications are best-effort. And account related notifications are also out of scope. =20 Consensus: We are only talking about email-related notifications, not calendar notifications, and these can be sent with a number of protocols. =20 Structured notifications or free text? Use cases? Security needed for notifications Focus on MWI first (e.g., using IMAP IDLE), leave the user details to SIEVE draft. That is no subject or other data. However, the SIP MWI already does this - counts are reliable, the other data is not. =20 Consensus: Reuse RFC 3842 - or an XMPP clone of it if necessary, unless a good argument is made to the contrary. Summary: 1. notifications scope is e-mail 2. follow _model_ of RFC 3842 3. figure out transport later ... 4. find a 6 year old editor... ------_=_NextPart_001_01C75799.B38A86E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Notes from the Jan 25th jabber chat on notifications

LEMONADE Notifications chat
January 25, 2007
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

Full log:
= http://www.ietf.org/meetings/ietf-logs/lemonade/2007-01-25.html

Online personalities:

      bernard.desruisseaux
      eburger – Eric Burger
      alexeymelnikov
      Glenn Parsons
      Dave = Cridland
      Ams -  Abhijit = Menon-Sen
      Lisa – Lisa = Dusseault
      Arnt – Arnt = Gulbrandsen
      Rohan – Rohan = Mahy

Discussion
-------------

Current = documents:

      draft-newman-lemonade-msgevent-00
      draft-ietf-lemonade-notifications-03
      OMA MEM REQ & = AD
      draft-mahy-sieve-notify-sip-00

Types of = notifications

  • out of = band
  • real = time
  • various transport = mechanisms – SIEVE, IMAP events, …

Types of out of band = notifications

  • new message = notification
  • new message = notification with different degrees of details
  • mailbox state = change notification
  • file = updated

Things to decide = about notifications:

  • how to send =
  • who to send = to
  • what to = send

Concern about = clients avoiding sync really being a subvertive IMAPv5

Concern on frequency = of SIEVE messages for notifications has been alleviated, however there = is still an issue on how to deal with multiple = devices.

SIEVE scripts (for = mobile devices) will tend to be semi-permanent, there was a concern = noted that designing for this might prohibit dynamic scripts.  = SIEVE is obvious for ‘user oriented’ notifications, but it = is overkill for MWI.  MWI is already defined using SIP (RFC 3842) = but is that necessary for email?

Notifications are = best-effort.  And account related notifications are also out of = scope.
 
Consensus:  We = are only talking about email-related notifications, not calendar = notifications, and these can be sent with a number of protocols.  =

Structured = notifications or free text?

Use = cases?

Security needed for = notifications

Focus on MWI first = (e.g., using IMAP IDLE), leave the user details to SIEVE draft.  = That is no subject or other data.  However, the SIP MWI already = does this – counts are reliable, the other data is = not.  

Consensus:  = Reuse RFC 3842 – or an XMPP clone of it if necessary, unless a = good argument is made to the contrary.


Summary:

  1. notifications scope = is e-mail
  2. follow _model_ of = RFC 3842
  3. figure out = transport later
    …
  4. find a 6 year old = editor…


------_=_NextPart_001_01C75799.B38A86E7-- --===============1981068551== 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 --===============1981068551==--