Subject: [dispatch] [Fwd: RE: Preliminary version of Expert review ofdraft-avasarala-dispatch-comm-div-notification-03]

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Feb 2010 15:17:21 -0500

-------- Original Message --------
Subject: RE: [dispatch] Preliminary version of Expert review 
ofdraft-avasarala-dispatch-comm-div-notification-03
Date: Fri, 19 Feb 2010 01:08:59 +0800
From: Avasarala Ranjit-A20990 <[email-masked]>
To: Paul Kyzivat <[email-masked]>
CC: Adam Roach <[email-masked]>, John-Luc Bakker <[email-masked]>
References: <[email-masked]> 
<[email-masked]><[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]> 
<[email-masked]>

Hi Paul, Adam

Since communication diversion notification information is not related to
any state of the actual communication, I feel there is no need to
maintain state for this. Also the Communication diversion notification
message gets triggered after the communication diversion has occurred.

The main intent of CDIVN is to notify the subscriber of a communication
diversion that occurred on their behalf in the network. This
notification is not part of any communication dialog or part of the
communication state machine and is completely independent of the actual
communication (or call).

Comments?

Thanks

Regards
Ranjit

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, February 18, 2010 8:05 AM
To: Avasarala Ranjit-A20990
Cc: Adam Roach; John-Luc Bakker
Subject: Re: [dispatch] Preliminary version of Expert review
ofdraft-avasarala-dispatch-comm-div-notification-03

Ranjit,

[ taking IESG off the dist list for now, and adding Adam as the sub/not
author. Perhaps we should take this back to the dispatch list. ]

I haven't had time to read through the revised document yet, but I
skimmed through your comments. There is one that I think we need to talk
about because it potentially has significant impact. (I've picked the
first place it came up, but its also mentioned in other parts of my
issues and your responses.)

Adam: Is this enough for you to understand the issue?

Avasarala Ranjit-A20990 wrote:

>> ISSUE: The document details the notification body, and some 
>> inferences
> 
>> can be drawn about the state from the syntax of the notification
body.
>> But this is tenuous. There should be an explicit specification of the

>> state maintained, and how it is mapped onto the notification body.
> 
> <Ranjit-Feb16> The notifications for communication diversions are sent

> as and when they occur depending on the filter criteria set by the 
> subscribers. So there is no need of maintaining any state information 
> for the package.

That doesn't fit my understanding of how event packages are defined.

IIUC, the semantics of event packages are described relative to some
sort of "state", not against another incoming event. (Whether this is
literally true in the implementation or not.)

So minimally, when a diversion happens, some particular information is
culled from it, and becomes the new state. Then that causes
notifications to the existing subscriptions.

After that it either sticks around, or else the state transitions back
to "none". But if it transitions back to "none" then that would trigger
another round of notifications - which you clearly don't want.

So it makes sense that it sticks around, in which case, when a new
subscription comes in it will get a notification about that last
diversion. (Unless there can be some sort of "implicit" filter that
suppresses notification when the state becomes "none".)

Adam - is that valid???

	Thanks,
	Paul