headers
Rohan Mahy | 19 Jun 2007 20:39
Picon

comments on draft-dusseault-email-notif-model-00

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Lisa Dusseault | 29 Jun 2007 23:33
Favicon

Re: comments on draft-dusseault-email-notif-model-00

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:

> 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.  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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Rohan Mahy | 2 Jul 2007 00:31

Re: comments on draft-dusseault-email-notif-model-00

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
(Continue reading)

Permalink | Reply | 4 comments |

Gmane