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

From: Rohan Mahy <[email-masked]>
Date: Sun, 1 Jul 2007 15:31:00 -0700

Hi Lisa,

Sorry it took me so long to get back to your comments.

I also noticed one other thing.  The CNA and the client could be in  
the same domain, so the domain boundary in your diagram between these  
two is optional.

Comments inline.

On Jun 29, 2007, at 2:33 PM, Lisa Dusseault wrote:
> Hi Rohan,
>
> I'm working through your comments and they're definitely going to  
> help do a much better 2nd rev.

I hope they do help.

> 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.
I don't think these need to be defined separately.  I will try to  
provide some concrete proposals here:

For one thing, the sub-pub terminology is XMPP-specific.  Both SIP  
and XMPP have a concept of a subscription.  Both have events  
generated about those subscriptions.  In XMPP these events are pubs;  
in SIP these events are notifications.  In SIP, a publication is a  
completely different thing entirely (it is a push).  So, in your  
diagram, you could replace "publish" with "event" throughout.  The  
PNA term still works fine since in XMPP it is aggregating *for* pubs  
and in SIP it is aggregating *from* pubs. :-)

> the subscription request is an implicit authorization, along each  
> step of the publish-subscribe chain
In SIP, the subscription request would likely go directly to the  
PNA.  The CNA would merely verify the identity claimed by the client  
and forward the subscription request to the PNA. Instead, I propose  
"the subscription request contains an implicit authorization, by the  
client and the CNA".  This should work for both.

> 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.
This does not jive with the expansion of the CNA acronym. The "A" in  
CNA stands for *Aggregator*?  What is the CNA aggregating if the PNA  
is already aggregating everything?

> 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:[email-masked]") 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?

probably a user name.  For example:  sip:[email-masked]
For XMPP, I think a fully qualified jid pointing to the notification  
resource would make sense.

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

RFC 3840 .  The official title changed pretty late, so I still think  
of it as callee-caps.

> I know that RFC3841 is Caller Preferences for SIP, but how would  
> that be used or what problems would it solve here?

If the Authoritative SIP proxy server for "example.com" is configured  
to know about the PNA, the proxy can configure what looks like a  
static registration for the PNA.

Contact: <sip:pna.example.com>;methods="SUBSCRIBE"
  ;events="message-summary"
  ;type="application/x-foobar-notification-format"

Then when a subscribe comes in, a proxy doing Caller Preferences  
routing, can use the presence of the method in the request, the event  
name in the Event header, and the notification body format in the  
Accept header to route to a UA instance that can handle that type of  
Event.

SUBSCRIBE sip:[email-masked] SIP/2.0
Event: message-summary
Accept: application/x-foobar-notification-format

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

I think the important thing to mention is that the PNA can use local  
administrative policy to decide whether the identity of the  
subscriber is considered equivalent to the owner of the mailbox, or  
is otherwise explicitly authorized to receive notifications.  
Providing the user login an password could actually make the overall  
system security worse instead of better.

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

For email event notifications, clients specify which user or resource  
and which server or domain is the target of its SUBSCRIBE request,  
and place this in a SIP URI called the Request URI.  The client also  
specifies the name of the Event package, and what notification  
formats are acceptable. If the subscription request needs to specify  
a particular mailbox, the event package could define a new SUBSCRIBE  
body format or an extra parameter to the Event header. A SUBSCRIBE  
body always acts as a filter for the specific subscription.

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

"It's impossible today" is both untrue and a red herring.  I think  
what you mean is "it isn't standardized today" which is irrelevant,  
since we are discussing developing new protocols and data formats.

As I demonstrated in my draft, I can write a PNA-like notifier and a  
SIP client that do this today without having to define any new IETF  
protocols.  I would have to use a vendor-specific MIME type and  
schema and I would use the sieve notification verb with a URI scheme  
which is not documented in any sieve spec.  This doesn't even present  
a process barrier.

The much more important question is why do so many people in the  
email community feel that processing a per-subscription sieve  
document for this purpose (as opposed to an arbitrary sieve document)  
is a problem?  It is extremely cheap to generate on the client, and  
it still scales linearly with the number of users and messages on the  
PNA.

As for the next version of the draft, I strongly suggest that you  
make the following two changes:
1) drop the word SIEVE from the title of Section 6.
2) in Section 2.1:
s/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 architecture ignores and defers discussion of unsolicited  
notifications generated by SIEVE or other sources until Section 6./

thanks,
-rohan

_______________________________________________
Notifications mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/notifications

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Jul 2007 08:43:29 -0700

On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote:

> This does not jive with the expansion of the CNA acronym. The "A"  
> in CNA stands for *Aggregator*?  What is the CNA aggregating if the  
> PNA is already aggregating everything?

I could have used the word proxy or server and I'm not sure why I  
didn't.  I expect sometimes the software the CNA and the PNA are  
running will be just the same, only their role will be different.  So  
I would rather not use "Consumer Notification Server" and "Publisher  
Notifications Aggregator" or readers will think it is two specialized  
servers.  Is "Server" better for both?

Aren't there cases where a SIP CNA will act as an aggregator and  
forward events to more than one device?  It's not required of the  
CNA, but isn't it likely?

Lisa

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Jul 2007 08:51:17 -0700

On Jul 1, 2007, at 3:31 PM, Rohan Mahy wrote:

> If the Authoritative SIP proxy server for "example.com" is  
> configured to know about the PNA, the proxy can configure what  
> looks like a static registration for the PNA.
>
> routing, can use the presence of the method in the request, the  
> event name in the Event header, and the notification body format in  
> the Accept header to route to a UA instance that can handle that  
> type of Event.
>

Trying to be sure I understand this here.  You're assuming that the  
authoritative SIP proxy server for example.com is a different server  
than the "PNA" for example.com, right?  I had been thinking these  
were often -- but not necessarily -- the same server.   If these are  
the same server, then the static registration isn't necessary, of  
course.   If these are not the same server, then why isn't this just  
transparent to everybody outside the example.com administrative domain?

thanks,
Lisa

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 2 Jul 2007 12:12:31 -0700

On 7/2/07, Lisa Dusseault <[email-masked]> wrote:
> I know that RFC3841 is Caller Preferences for SIP, but how would that be
> used or what problems would it solve here?
>
> If the Authoritative SIP proxy server for "example.com" is configured to
> know about the PNA, the proxy can configure what looks like a static
> registration for the PNA.
>
> Then when a subscribe comes in, a proxy doing Caller Preferences routing,
> can use the presence of the method in the request, the event name in the
> Event header, and the notification body format in the Accept header to route
> to a UA instance that can handle that type of Event.
>
> authoritative SIP proxy server for example.com is a different server than
> the "PNA" for example.com, right?  I had been thinking these were often --
> but not necessarily -- the same server.   If these are the same server, then
> the static registration isn't necessary, of course.   If these are not the
> same server, then why isn't this just transparent to everybody outside the
> example.com administrative domain?

If the authoritative server is the same, there is just some internal
configuration so the server knows it needs to handle such-and-such
event packages itself.  If they are not the same, the server can be
configured to route incoming SUBSCRIBE requests to the correct SIP
server (the PNA).  The outside world can't assume it knows how the
"example.com" domain wants to handle some SIP requests to
sip:[email-masked] differently from others.  That's local
administrative policy. If an external entity decides to send INVITEs
to example.com (sip:[email-masked]), but somehow instead sends
SUBSCRIBEs to pna.example.com (sip:[email-masked]) that is also
perfectly fine, but not as convenient for the subscriber.

This is no different from XMPP routing request of a specific type from
 bare JID (xmpp:[email-masked]) to a specific resource
(xmpp:[email-masked]/msgevents) instead of addressing that resource
directly.  Likewise, a web proxy or redirector can point requests for
http://(www.)example.com/webmail to http://webmail.example.com, or the
HTTP user agent can go there directly.

hope that helps.
thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 2 Jul 2007 12:27:00 -0700

On 7/2/07, Lisa Dusseault <[email-masked]> wrote:
> 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.
>
> This does not jive with the expansion of the CNA acronym. The "A" in CNA
> stands for *Aggregator*?  What is the CNA aggregating if the PNA is already
> aggregating everything?
> I could have used the word proxy or server and I'm not sure why I didn't.  I
> expect sometimes the software the CNA and the PNA are running will be just
> the same, only their role will be different.  So I would rather not use
> "Consumer Notification Server" and "Publisher Notifications Aggregator" or
> readers will think it is two specialized servers.  Is "Server" better for
> both?

I think PNA and CNS are fine.  Its also fine to point out that these
are logical roles and they can be combined.

> Aren't there cases where a SIP CNA will act as an aggregator and forward
> events to more than one device?  It's not required of the CNA, but isn't it
> likely?

This is a crux of the problem.  I think the answer to both is a very
firm NO. Why does a PNA in one domain trust the CNA in another to do
aggregation on its behalf? Why is the CNA willing to take on the work
of aggregating and amplifying subscriptions from another domain?  How
does the CNA know which subscribing identities share the same
notifications and which do not, without violating the privacy of this
information?  Why did we draw a domain boundary in the architecture
picture in the first place? These are the sort of blind trust
assumptions that tend to get us into trouble.

Finally, I ask what real benefit would we get from this aggregation if
we did implement it?  What are we trying to optimize?  Certainly
optimizing bandwidth between servers in two domains which are often
colocated at fast peering points should be a non-goal. The number of
subscribers for Alice's mailbox events is likely to be relatively
small (under 10), so trying to offload onto the CNA to optimize the
processing on the PNA saves very little.  Indeed, the CNA needs at
least one subscription to the PNA, and one subscription from the
client if it plans to aggregate, while proxying a subscription results
only in one subscription from the client to the PNA.  If the average
number of subscribing clients per mailbox is less than two, we've
generated MORE state and more messaging traffic.

thanks,
-rohan