Subject: [Notifications] comments on draft-dusseault-email-notif-model-00

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 19 Jun 2007 11:39:57 -0700

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:[email-masked]") 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 29 Jun 2007 14:33:55 -0700

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:

> draft-dusseault-email-notif-model-00. ...
>

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.

> "NOTIF=sip:[email-masked]") including an optional

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?

> 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?

> authenticate the mail server itself.

I need to read http://www.ietf.org/rfc/rfc4474.txt.  More work  
definitely needed here.

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

> 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