Subject: Re: [dispatch] Expert review ofdraft-avasarala-dispatch-comm-div-notification-04

From: "Elwell, John" <[email-masked]>
Date: Mon, 14 Feb 2011 09:36:21 +0100

I know this has been discussed at length before, but it still seems to me that when a NOTIFY request is sent, some sort of state change occurs at the notifier, i.e., the value M (which appears to be part of the state information) is decremented. Is this compliant with RFC 3265 (or bis)? Does M get decremented when the NOTIFY request is sent or when the 200 OK arrives? What about repeats (e.g., when a subscription is lost and has to be re-established)? What about multiple subscribes - how does M relate to a single subscriber or all subscribers? Each time a SUBSCRIBE request arrives (in accordance with the "polling resource state" section 3.3.6 of RFC 3265 /section 4.4.3 of RFC 3265bis), it seems the subscriber will receive something different in the resultant notify request - is this true, or does the fact that M is decremented each time have no impact on what the subscriber receives.

Some of the language in 6.7 is certainly rather hard to figure out. For example "in
   addition to this it is also REQUIRED that the notifiers maintain the
   list of last M communication diversion notifications sent to the
   user, where M equal to or less than N. M equals N if notifications
   are sent for all communication diversions that occurred.  The value M
   is decremented whenever a communication diversion notification is
   sent to the user."
I can't relate the fact that M reflects the number of notifications **sent**, yet M is **decremented**, not incremented, each time a notification is sent. Is M supposed to be a negative number or what?

"The notifiers check the value of M as being
   greater than 0 prior to generating the notification information."
What happens if it is 0? Does no notification get sent, or what? If the sending of a notification is dependent on the value of M, this seems to prove my point that state changes occur as a result of sending notifications, which doesn't seem to be in accordance with the principles of RFC 3265.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 12 February 2011 23:02
> To: Avasarala Ranjit-A20990
> Cc: Cullen Jennings; Elwell, John;
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> John-Luc Bakker
> Subject: Re: [dispatch] Expert review
> ofdraft-avasarala-dispatch-comm-div-notification-04
>
> Ranjit,
>
> I reviewed this, again. I found that it already advanced to -07 to
> address comments from other 3gpp people. I don't have any comments on
> *those* changes, so here I comment on the changes from -05 to -06.
>
> Disclaimers:
> - I did not investigate the referenced 3gpp and tispan
>    requirements documents.
> - As always, I have not audited the XML examples and schema
>    for correctness. An XML expert should do that.
>
> Section 6.6:
>
> > In case the Notifier does not support filter criteria, then
> it should
> > ignore it or send a suitable 4xx response. E.g. 415 response.
>
> This is pretty vague. Is this normative? (It doesn't use normative
> language.) Seems to me that whether to ignore or send 415 ought to be
> well defined.
>
> Sending 415 is a little odd, because the same content-type is
> used for
> both subscribe and notify, and clearly the notifier will be
> supporting
> that type for sending notifications. Technically the Accept indicates
> what the UA can *receive* so its not really ambiguous, but it may be
> confusing to implementors. It would be much clearer in this and other
> respects if there were separate content-types for the filter body and
> the notification body.
>
> Also in this section is:
>
> > The Notifier SHALL then compute the state information as defined in
> > Section 6.11 for the subscriber and send a NOTIFY request to the
> > subscriber.
>
> The problem I have with this is that section 6.11 does not
> say much of
> anything about how the state information is computed. It especially
> doesn't say anything about how filters affect that.
>
> I think a fundamental concept is *still* not discussed (understood?):
>
> There *ought* to be some state information about the
> *resource* (in this
> case that is the uri being diverted I think). In any case its
> independent of specific subscriptions. It changes as
> diversions occur.
> As each diversion occurs, some set of attributes about that
> (e.g. time,
> caller, reason for diversion) are captured. And perhaps at that time
> some old state is discarded.
>
> Then there is the *view* of that state as seen by a particular
> subscriber, which is affected by the filter supplied. This
> view may be
> identical to the complete state, or it may be a subset. This affects
> whether a notification is sent, as well as what is contained in it.
>
> A reader can *guess* at what how you intend the filter to affect the
> mapping between the full state and the subscriber's view of it. But
> there is no text discussing this. I can't even guess whether all
> specified criteria must match (AND) or just one must match
> (OR) for the
> filter to select a particular diversion for inclusion in the
> subscriber's view. This needs to be spelled out clearly so that all
> implementations agree.
>
> Section 6.7:
>
> I don't understand the keeping history of the last M
> notifications. What
> is the purpose of that? If you intend to generate delta notifications
> (of only that which is new since the last notification), then
> you need
> to keep the most recent notification. I don't understand the value of
> keeping more. Also, the record of most recent notification
> really needs
> to be done on a per-subscription basis. (Its really state about the
> subscription.) If there are multiple subscriptions then you
> would need
> one instance for each. Is that the M you are talking about?
>
> I also don't understand the following:
>
> > As a server policy, the values of N and M SHOULD be reset to 0
> > after reaching the maximum configured value to avoid overflows
>
> These values are described as *policy* values (how *much* history to
> keep). I understand that when the amount of history has reached the
> policy limit, then new data can't be kept without discarding some old
> data. But that doesn't change the limits.
>
> I also am wondering about the following:
>
> > The Notifier MAY choose not to send NOTIFY to the subscriber if the
> > computed state information is same as the previously stored. This
> > is left to server policy.
>
> I want to double check what you mean here. (This may need
> some further
> clarification.) Is the situation you describe one where:
> - there was an earlier notification
> - a new diversion has occurred, but because of a filter,
>    the new notification would turn out to be identical to the
>    prior one. (The new diversion is filtered out, and any history
>    that isn't filtered out is unchanged.)
>
> NIT:
>
> There is a typo at the end of section 6.3: "Section Section 8.1.1".
>
>       Regards,
>       Paul
>
>
> On 2/9/2011 9:13 AM, Avasarala Ranjit-A20990 wrote:
> > Hi Paul, John, Keith, Adam, Mary, Gonzalo
> >
> > I have submitted an updated version of the draft today
> addressing John's
> > and Paul's expert review comments. The URL for the -06
> version of the
> > draft is:
> >
> http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notif
> ication-06
> > .txt.
> >
> > I have also attached the excel document highlighting the
> expert review
> > comments and their corresponding resolution in the updated draft.
> >
> > Please review and comment the next course of action.
> >
> > Regards
> > Ranjit
> >
> > -----Original Message-----
> > From: [email-masked]
> [mailto:[email-masked]] On
> > Behalf Of Paul Kyzivat
> > Sent: Tuesday, April 06, 2010 1:59 AM
> > To: Mary Barnes; Cullen Jennings
> > Cc: [email-masked]
> > Subject: [dispatch] Expert review
> > ofdraft-avasarala-dispatch-comm-div-notification-04
> >
> > I was asked to be expert reviewer for this document.
> > I earlier reviewed version -03, and this is an updated
> review of -04.
> > Some of the issues I raised previously have been resolved,
> but not all.
> >
> > RFC 5727 calls for me to judge it just like a standards
> track document,
> > and doing so leads to most of the remaining issues. I don't
> think I have
> >
> > raised any fundamentally new issues since the previous
> pass, though I
> > have tried to restate the remaining ones in context of the
> new document
> > and the intermediate discussions we have had.
> >
> > I continue to think this is mostly a matter of getting the
> text right,
> > rather than altering the fundamental aspects of the
> proposed package.
> > Mostly this is a matter of insufficient text, leaving many
> ambiguities.
> >
> >     Thanks,
> >     Paul
> >
> >
> >
> ==============================================================
> ==========
> > ==
> >
> > I was requested to do an expert review of
> > draft-avasarala-dispatch-comm-div-notification-04.txt
> >
> >>     1.  A Designated Expert (as defined in RFC5226) must review the
> >>         proposal for applicability to SIP and conformance
> with these
> >>         guidelines.  The Designated Expert will send email
> to the IESG
> > on
> >>         this determination.  The expert reviewer can cite
> one or more
> > of
> >>         the guidelines that have not been followed in
> his/her opinion.
> >
> > I'm doing that below.
> >
> >>     2.  The proposed extension MUST NOT define an event
> > template-package.
> >
> > It does not.
> >
> >>     3.  The function of the proposed package MUST NOT overlap with
> >>         current or planned chartered packages.
> >
> > I am aware of no chartered work on this subject.
> > The draft itself has been debated at length on the dispatch
> wg mailing
> > list, but with a relatively small number of people actively
> involved.
> > Some, including me, have stated that a service resembling the one
> > proposed might be of general utility. But there have been
> no volunteers
> > to do the work of generalizing this. So I conclude that there are
> > currently no plans for chartered work on such a package.
> >
> >>     4.  The event package MUST NOT redefine or contradict
> the normative
> >>         behavior of SIP events [RFC3265], SIP [RFC3261], or related
> >>         standards track extensions.  (See Section 4)
> >
> > I did not identify any issues in this regard.
> >
> >>     5.  The proposed package MUST NOT undermine SIP security in any
> >>         sense.  The Internet Draft proposing the new package MUST
> > address
> >>         security issues in detail as if it were a Standards Track
> >>         document.  Security issues need to be discussed
> for arbitrary
> >>         usage scenarios (including the general Internet case).
> >
> > The document identifies the specific security issues
> presented by this
> > package. It specifies that authentication and authorization must be
> > done, but leaves the means for authorization out of scope.
> While a bit
> > thin, this may be sufficient for the area of applicability.
> >
> >>     6.  The proposed package MUST be clearly documented in an
> >>         (Individual) Informational RFC, and registered with IANA.
> >
> > The document under review will satisfy this requirement.
> >
> >>         The package MUST document all the package considerations
> > required
> >>         in Section 4 of SIP events [RFC3265].
> >
> > I will comment on the individual parts of section 4 below:
> >
> >> 4.1. Appropriateness of Usage
> >
> > In my opinion this is an entirely appropriate use of sip and event
> > packages.
> >
> >> 4.2. Event Template-packages
> >
> > N/A - template package not defined.
> >
> >> 4.3. Amount of State to be Conveyed
> >
> >> 4.3.1. Complete State Information
> >> 4.3.2. State Deltas
> >
> > This version of the document is improved - it now discusses the
> > retention of state about some number of past diversions.
> But it does not
> >
> > discuss *what* state information is captured from a
> diversion. This is
> > *implied* by the specification of the xml document that conveys this
> > information in NOTIFY requests.
> >
> > This is tenuous. There should be an explicit specification of the
> > state maintained, and how it is mapped onto the notification body.
> >
> > There is no normative requirement to include this information in the
> > document, so I can't insist on it. But without this, it will be
> > difficult to adequately address Notifier generation of
> NOTIFY requests.
> >
> >> 4.4. Event Package Responsibilities
> >> 4.4.1. Event Package Name
> >
> > OK.
> >
> >> 4.4.2. Event Package Parameters
> >
> > OK.
> >
> >> 4.4.3. SUBSCRIBE Bodies
> >
> > ISSUE: The schema for the body type allows parts of types
> > <comm-div-subs-info>  and<comm-div-ntfy-info>. It appears that only
> > <comm-div-subs-info>  should appear in a SUBSCRIBE request,
> but this is
> > not specified.
> >
> > There should either be text specifying that this part must not be
> > present, or else text explaining what is to happen if it is present.
> >
> >> 4.4.4. Subscription Duration
> >>
> >>     It is RECOMMENDED that event packages give a suggested range of
> > times
> >>     considered reasonable for the duration of a subscription.  Such
> >>     packages MUST also define a default "Expires" value to
> be used if
> >>     none is specified.
> >
> > OK.
> >
> >> 4.4.5. NOTIFY Bodies
> >
> > ISSUE: The schema for the body type allows parts of types
> > <comm-div-subs-info>  and<comm-div-ntfy-info>. It appears that only
> > <comm-div-ntfy-info>  should appear in a NOTIFY request,
> but this is not
> > specified.
> >
> > There should either be text specifying that this part must not be
> > present, or else text explaining its significance in a NOTIFY.
> >
> >> 4.4.6. Notifier processing of SUBSCRIBE requests
> >
> > ISSUE: There is no text stating that the notifier must retain the
> > information from the body of the subscribe for use in generation of
> > NOTIFY requests. Since that is certainly required, it
> should be stated.
> >
> > ISSUE: There is no specification of what to do if the subscribe body
> > contains<comm-div-ntfy-info>. If that's valid, then the
> behavior should
> >
> > be specified. If its not valid, that should have been specified in
> > 4.4.3.
> >
> >> 4.4.7. Notifier generation of NOTIFY requests
> >>
> >>     This section of an event package describes the process
> by which the
> >>     notifier generates and sends a NOTIFY request.  This includes
> >>     detailed information about what events cause a NOTIFY
> to be sent,
> >
> > ISSUE: the triggers for sending NOTIFY are imprecisely specified.
> > This is *partially* covered, in that it it states that a NOTIFY will
> > "typically" be sent when "a communication diversion is
> enacted on behalf
> >
> > of the user", but the atypical situation is not discussed.  There is
> > also "A notifier MAY send a NOTIFY at any time", which appears to be
> > inappropriate - apparently the only other time to send such a
> > notification is immediately following a SUBSCRIBE request.
> >
> > ISSUE: There is no discussion of how the body from the
> SUBSCRIBE request
> >
> > affects the decision about when to send NOTIFY requests.
> >
> > This is too under-specified to be considered complete.
> >
> > What I would expect to see here is, roughly:
> >
> > - when a new (or refresh) SUBSCRIBE is received, compute the state
> >     information in the notify (see below), and send regardless of
> >     whether it is empty or not.
> >
> > - when a communication diversion occurs, selected
> attributes (TBS) of
> >     the diverted message and the diversion itself are captured and
> >     saved as new diversion state.
> >
> > - the addition of this new state may (or may not) result in
> discarding
> >     some old state. (Details TBS, related to the value N.)
> >
> > - for each subscriber, compute the state information in the notify
> >     (see below). If the resulting body is non-empty, send
> the NOTIFY.
> >     If empty, do not send the notify.
> >
> >>     how to compute the state information in the NOTIFY,
> >
> > ISSUE: I don't find this information anywhere. While an
> implementor may
> > attempt to infer it from the descriptions of the subscribe
> and notify
> > bodies, that doesn't constitute a specification.
> >
> > ISSUE: The subscribe body is intended to be used as a
> filter on which
> > events/state are reported. The subscribe body contains data
> to be used
> > in the filtering process, but the decision process for
> filtering is not
> > specified. For instance, both a User-name and a User-URI may be
> > provided. It is implied, rather than stated, that the
> User-name field is
> > matched against the user portion of some URI, whereas the
> User-URI field
> > is matched against a complete URI. Also, there are a
> variety of field
> > types, and no indication how matches of multiple fields are
> combined.
> > (I.e. AND or OR.)
> >
> > I would expect to see a description of how the content of
> the subscribe
> > body is applied to the saved diversion state to format a
> notify body.
> > Also, how to construct the notify body if there is no
> subscribe body.
> > Also, the representation of an "empty" body when there is no saved
> > diversion state or the subscribe body results in all of the saved
> > information being withheld from the subscriber.
> >
> >>     how to generate
> >>     neutral or fake state information to hide
> authorization delays and
> >>     decisions from users, and whether state information is
> complete or
> >>     deltas for notifications; see section 4.3.  Such a section is
> >>     required.
> >
> > ISSUE: This is not discussed.
> >
> > AFAICT, there is no need for fake information - this can simply be
> > stated. Neutral information is presumably what is sent in a
> NOTIFY when
> > there is no saved diversion state, or all saved state is
> filtered out by
> >
> > the subscribe body. Apparently the intent in that case is
> for a NOTIFY
> > with no body. That should be made clear.
> >
> >> 4.4.8. Subscriber processing of NOTIFY requests
> >
> > This section is very thin - it specifies nothing.
> >
> > But if you want to leave this undefined I won't object,
> because there
> > appear to be no normative requirements.
> >
> >> 4.4.9. Handling of forked requests
> >
> > OK, not permitted.
> >
> >> 4.4.10.  Rate of notifications
> >
> > OK - specified.
> >
> >> 4.4.11.  State Agents
> >
> > Its my understanding that this event package is not
> intended to employ
> > state agents (as that term is defined in RFC 3265). Hence
> this section
> > should simply state that state agents are not used.
> >
> >> 4.4.12.  Examples
> >
> > The only provided example is a sample of a notification body.
> > Flow diagrams and message detail, as called out in 3265,
> would be very
> > useful. Specifically, this document would be improved if it included
> > examples of at least:
> >
> > - initial subscribe when there have been no diversions
> >
> > - the occurrence of a diversion and the resulting notification
> >     to existing subscribers.
> >
> > - another subscription by another subscriber while there is
> >     retained state from a prior diversion, and the resulting
> >     notification(s).
> >
> > - another diversion occurrence, its impact on saved state,
> >     and on what the existing subscribers receive as notifications.
> >
> > - a subscription with a filter that screens out some but not all
> >     of the diversions in the saved state.
> >
> > Having such examples might have shortened the discussion of
> this draft
> > significantly. But this is not mandatory according to 3265,
> so I cannot
> > require that you provide it.
> >
> > NIT: Section 8.2 is entitled "Sample Notification Body",
> but it contains
> > subsections entitled "Instance of communication diversion
> subscription
> > document" and "Instance of communication diversion notification
> > document". While the latter would be a notification body, the former
> > would presumably be a subscription body. I suggest you rename the
> > section to be more clear.
> >
> >> 4.4.13.  Use of URIs to Retrieve State
> >
> > OK - not used.
> >
> >>     7.  If determined by the Designated Expert or the
> chairs or ADs of
> >>         the DISPATCH WG, an applicability statement in the
> > Informational
> >>         RFC MUST clearly document the useful scope of the
> proposal, and
> >>         explain its limitations and why it is not suitable for the
> >>         general use of SIP in the Internet.
> >
> > The Applicability Statement in the document adequately documents the
> > scope.
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Feb 2011 09:59:11 -0500

Ranjit,

Disclaimers:

Section 6.6:

> In case the Notifier does not support filter criteria, then it should

Sending 415 is a little odd, because the same content-type is used for 
both subscribe and notify, and clearly the notifier will be supporting 
that type for sending notifications. Technically the Accept indicates 
what the UA can *receive* so its not really ambiguous, but it may be 
confusing to implementors. It would be much clearer in this and other 
respects if there were separate content-types for the filter body and 
the notification body.

> Section 6.11 for the subscriber and send a NOTIFY request to the

The problem I have with this is that section 6.11 does not say much of 
anything about how the state information is computed. It especially 
doesn't say anything about how filters affect that.

There *ought* to be some state information about the *resource* (in this 
case that is the uri being diverted I think). In any case its 
independent of specific subscriptions. It changes as diversions occur. 
As each diversion occurs, some set of attributes about that (e.g. time, 
caller, reason for diversion) are captured. And perhaps at that time 
some old state is discarded.

Then there is the *view* of that state as seen by a particular 
subscriber, which is affected by the filter supplied. This view may be 
identical to the complete state, or it may be a subset. This affects 
whether a notification is sent, as well as what is contained in it.

specified criteria must match (AND) or just one must match (OR) for the 

Section 6.7:

I don't understand the keeping history of the last M notifications. What 
is the purpose of that? If you intend to generate delta notifications 
(of only that which is new since the last notification), then you need 
to keep the most recent notification. I don't understand the value of 
keeping more. Also, the record of most recent notification really needs 
to be done on a per-subscription basis. (Its really state about the 
subscription.) If there are multiple subscriptions then you would need 
one instance for each. Is that the M you are talking about?

> is left to server policy.

I want to double check what you mean here. (This may need some further 

NIT:

	Regards,
	Paul

On 2/9/2011 9:13 AM, Avasarala Ranjit-A20990 wrote:
> I have submitted an updated version of the draft today addressing John's
> and Paul's expert review comments. The URL for the -06 version of the
> draft is:
> http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-06
> .txt.
>
> I have also attached the excel document highlighting the expert review
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> I earlier reviewed version -03, and this is an updated review of -04.
> Some of the issues I raised previously have been resolved, but not all.
>
> RFC 5727 calls for me to judge it just like a standards track document,
> and doing so leads to most of the remaining issues. I don't think I have
>
> raised any fundamentally new issues since the previous pass, though I
> have tried to restate the remaining ones in context of the new document
> I continue to think this is mostly a matter of getting the text right,
> rather than altering the fundamental aspects of the proposed package.
> Mostly this is a matter of insufficient text, leaving many ambiguities.
>
> 	Thanks,
> 	Paul
>
>
> ========================================================================
> ==
>
>>         proposal for applicability to SIP and conformance with these
>>         guidelines.  The Designated Expert will send email to the IESG
> on
>>         this determination.  The expert reviewer can cite one or more
> of
>>         the guidelines that have not been followed in his/her opinion.
>
> I'm doing that below.
>
> The draft itself has been debated at length on the dispatch wg mailing
> list, but with a relatively small number of people actively involved.
> proposed might be of general utility. But there have been no volunteers
>>     4.  The event package MUST NOT redefine or contradict the normative
>>         document.  Security issues need to be discussed for arbitrary
> The document identifies the specific security issues presented by this
> done, but leaves the means for authorization out of scope. While a bit
> retention of state about some number of past diversions. But it does not
>
> discuss *what* state information is captured from a diversion. This is
> difficult to adequately address Notifier generation of NOTIFY requests.
>
> <comm-div-subs-info>  should appear in a SUBSCRIBE request, but this is
> not specified.
>
>>     packages MUST also define a default "Expires" value to be used if
>>     none is specified.
>
> OK.
>
>> 4.4.5. NOTIFY Bodies
>
> <comm-div-ntfy-info>  should appear in a NOTIFY request, but this is not
> specified.
>
> NOTIFY requests. Since that is certainly required, it should be stated.
>
> contains<comm-div-ntfy-info>. If that's valid, then the behavior should
>
>>     This section of an event package describes the process by which the
>>     detailed information about what events cause a NOTIFY to be sent,
>
> "typically" be sent when "a communication diversion is enacted on behalf
>
> ISSUE: There is no discussion of how the body from the SUBSCRIBE request
>
> - when a communication diversion occurs, selected attributes (TBS) of
> - the addition of this new state may (or may not) result in discarding
>     (see below). If the resulting body is non-empty, send the NOTIFY.
> ISSUE: I don't find this information anywhere. While an implementor may
> attempt to infer it from the descriptions of the subscribe and notify
> ISSUE: The subscribe body is intended to be used as a filter on which
> events/state are reported. The subscribe body contains data to be used
> in the filtering process, but the decision process for filtering is not
> provided. It is implied, rather than stated, that the User-name field is
> matched against the user portion of some URI, whereas the User-URI field
> is matched against a complete URI. Also, there are a variety of field
> types, and no indication how matches of multiple fields are combined.
> (I.e. AND or OR.)
>
> I would expect to see a description of how the content of the subscribe
> body is applied to the saved diversion state to format a notify body.
> Also, how to construct the notify body if there is no subscribe body.
>>     neutral or fake state information to hide authorization delays and
>>     decisions from users, and whether state information is complete or
> stated. Neutral information is presumably what is sent in a NOTIFY when
> there is no saved diversion state, or all saved state is filtered out by
>
> the subscribe body. Apparently the intent in that case is for a NOTIFY
> But if you want to leave this undefined I won't object, because there
> Its my understanding that this event package is not intended to employ
> state agents (as that term is defined in RFC 3265). Hence this section
> Flow diagrams and message detail, as called out in 3265, would be very
> Having such examples might have shortened the discussion of this draft
> significantly. But this is not mandatory according to 3265, so I cannot
> NIT: Section 8.2 is entitled "Sample Notification Body", but it contains
> subsections entitled "Instance of communication diversion subscription
>>     7.  If determined by the Designated Expert or the chairs or ADs of
>>         RFC MUST clearly document the useful scope of the proposal, and

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 14 Feb 2011 17:15:47 -0500

I *think* the idea is that the state information is the last N diversions, and that the subscriber's view of that state is the subset of the last N diversions that match the subscription's filtering criteria.  I suspect that "M" is the number of diversions in the subscriber's view.

It seems that it would be useful to define full and partial state, where "partial" state is the (filtered) set of diversions that have arrived since the last notification to the subscriber.  That would be consistent with other "partial" state definitions, since it would be essentially the difference between the current state and the previous state.

There is trouble with the XML examples in that there is extraneous whitespace around the character content of elements.

Dale