Subject: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt

From: "Avasarala, Ranjit" <[email-masked]>
Date: Fri, 21 Oct 2011 01:23:07 +0800

Hi all

I have uploaded updated version of draft-avasarala-dispatch-comm-div-notification-08.txt incorporating the following comments
a)      Updated the state information to reflect the CDIVN state and state diagram
b)      Added text to support subscription forking.

http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.txt

Please review and comment

Thanks

Regards
Ranjit

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Fri, 21 Oct 2011 01:26:46 +0800

Adding Paul

Regards
Ranjit

From: [email-masked] [mailto:[email-masked]] On Behalf Of Avasarala, Ranjit
Sent: Thursday, October 20, 2011 10:53 PM
To: [email-masked]
Cc: [email-masked]; Barnes, Mary
Subject: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt

Hi all

 1.  Updated the state information to reflect the CDIVN state and state diagram
 2.  Added text to support subscription forking.

Thanks

Regards
Ranjit

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 16:03:10 -0400

Ranjit,

I have just started to look at this version. It seems to be an 
improvement. Before I do a thorough review I'll bring up a few things 
that jumped out at me:

Section 6.5:

    All subscribers of "comm-div-info" event package who wish to add
    filter criteria to their subscription requests MUST support the
    application/comm-div-info-filter+xml" data format as described in
    Section 8.1.1 while the notifiers SHALL support the "application/
    comm-div-info+xml" data format as described in Section 8.1.2.  The
    SUBSCRIBE request MAY contain an Accept header field.  If no such
    header field is present, it has a default value of "application/
    comm-div-info-ntfy+xml" (assuming Event header has a value of "comm-
    div-info-ntfy").  If the Accept header field is present, it MUST
    contain the value "application/comm-div-info-ntfy+xml" only.

I think I know what you want to say, but this doesn't say it. What I 
think you are trying to say (or ought to be trying to say) is:

- the subscriber that wants a filter has to encode it according
   to the filter xml schema and indicate the content-type accordingly.

- the notifier MUST be capable of accepting the filter xml, in case
   a subscriber wants to use one.

- the subscriber must always Accept receiving a notify xml
   in the notify.

- the notifier MUST encode notifications according to the notify
   xml schema and indicate the content type accordingly.

- The default Accept for a subscribe to this package is the
   notify xml.

If I have that right, we can discuss how to write a paragraph that says 
it concisely and clearly.

I *think* that you are trying to allow notifiers that don't support 
filtering. I question the wisdom of that. And if you really want that, I 
think it would be helpful to consider what that means. Does it mean that 
the notifier ignores the presence of the filter document? Or does it 
mean that it recognizes the presence of the filter but chooses not to 
honor the filter? Could that refusal be partial? (I.e. it understands 
the document but chooses to not apply certain filter criteria?)

What about a subscriber that feels it needs the filter? It might choose 
not to subscribe if it can't have the filter. But then it either needs 
the subscribe to fail in that case, or else it needs a way to tell that 
the filter isn't being honored.

I would think it better to have the subscribe rejected with a 415 if the 
notifier doesn't support filtering, or else have the notify indicate 
that the requested filter is not being applied.

Section 6.11:

I appreciate your having provided a state diagram. But I don't 
understand it.

    +------------+  Diversion  +---------------+
    |            +--+--------->+               |
    |   IDLE     |  ^          |   DIVERSION   |
    |            |  |  +------>+   DETECTED    |
    +------------+  |  |       +--+----+-------+
                    |  | no match      |  |filter
                    +------------------+  |match
                       |                  v
                       |          +-------+-------+
                       |          |   DIVERSION   |
                       |          |    NOTIFIED   |
                       |          +-----+---------+
                       |    Diversion   |
                       +----------------+

As I read this, what I conclude is:

- the subscriber will not learn about any diversions which occurred
   prior to the subscription. (This may be what you intend.
   at least its easy.)

- the first diversion after subscribing moves to
   DIVERSION DETECTED state.

- upon entry to DIVERSION DETECTED, a filter match is
   attempted. (Presumably this always succeeds if there
   is no filter.)

- its unclear what happens if the filter fails to match.
   The transition for that connects to the Diversion
   transition. That would seem to create an infinite loop.
   I expect the "no match" transition ought to go to IDLE.

- if the filter match succeeds, DIVERSION NOTIFIED state
   is entered. No action is indicated. I suppose its implied
   that a notification is sent. Then apparently the subscription
   remains in this state until another diversion occurs.
   Then the transition is back to DIVERSION DETECTED, and
   things repeat.

I'm also puzzling over:

    The subscriber could receive, as part of the notification
    information, the state the FSM was in prior to detecting the
    diversion.

    o  [IDLE]: meaning that there have been no missed diversions since
       setting the present "filter".

    o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
       diversions.

    o  [DIVERSION_DETECTED]: meaning that there have been some missed
       diversions.

I don't get how that would work. It isn't going to report the missing of 
diversions that occurred prior to the subscribe, because the 
subscription always starts in the IDLE state. And I don't know how you 
miss diversions after the subscription is established.

That's all for now.

	Thanks,
	Paul

On 10/20/11 1:23 PM, Avasarala, Ranjit wrote:
> Hi all
> I have uploaded updated version of
> draft-avasarala-dispatch-comm-div-notification-08.txt incorporating the
> following comments
>
> _http://www.ietf.org/id/draft-avasarala-dispatch-comm-div-notification-08.txt_
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 22:09:29 +0200

Nitpicking, but anyway:

" The body of the NOTIFY MUST be sent using the type "application/
   comm-div-info-ntfy+xml" and must contain the elements defined in
   Section 8.1.2 only.  The Content-Type header field MUST be set to
   "application/comm-div-info-ntfy+xml".
"

The MUST here seems to stop any attempts at protecting the message
with S/MIME. If one turns the text around saying something like "there MUST be a
message of type YYY and the content-type of this body part must be
set to XXX" we are still open for S/MIME integrity as well as confidentiality.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 16:55:25 -0400

I was thinking about commenting on this but put it off.
The issue is more general - about handling multipart bodies.
RFC 5621 addresses this.

The rule should be something like:

The NOTIFY MUST contain a body part with Content-Type 
"application/comm-div-info-ntfy+xml" and Content-Disposition of "render" 
(or no Content-Disposition).

Its not ok to assume that the NOTIFY will contain only this body part.

	Thanks,
	Paul

On 10/20/11 4:09 PM, Olle E. Johansson wrote:
> Nitpicking, but anyway:
>
> "The body of the NOTIFY MUST be sent using the type "application/
>
>     Section 8.1.2  <http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-08#section-8.1.2>  only.  The Content-Type header field MUST be set to

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Mon, 24 Oct 2011 16:50:53 +0800

Hi Paul

My comments inline <Ranjit>

Regards
Ranjit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, October 21, 2011 1:33 AM
To: [email-masked]
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt

Ranjit,

Section 6.5:

If I have that right, we can discuss how to write a paragraph that says 
it concisely and clearly.
<Ranjit>
that seems "right". Except for:

In my opinion a notifier must always support the filter as it can't predict if a suberiber wants to use a filter.
<Ranjit>

<Ranjit> I am okay requiring the support for filters in the notifier 

<Ranjit> I am okay requiring the support for filters in the notifier. If still not supported, sending a 415 is sufficient (and subscription for this event then fails). 

Section 6.11:

<Ranjit> Correct

<Ranjit> Correct

<Ranjit> well if we require the support of a filter then we shouldn't get here "if there is no filter" as then there was a 415 response?

<Ranjit> well, we should transition to DIVERSION_DETECTED per "no match". The diversion did occur and was detected but no notification was sent. I would like to somehow express that the state machine stops at DIVERSION_DETECTED in this case. IDLE could be read as "NOTHING DETECTED" e.g. because there is no subscription so no need to detect anything.

- if the filter match succeeds, DIVERSION NOTIFIED state
   is entered. No action is indicated. I suppose its implied
   that a notification is sent.
<Ranjit> we clarify that a notification is sent

 Then apparently the subscription
   remains in this state until another diversion occurs.
   Then the transition is back to DIVERSION DETECTED, and
   things repeat.

<Ranjit> yes. So, I am not sure how to address the comment but perhaps the below diagram would capture the situation? Upon detecting the first diversion, we enter the state machine, we attempt to match filters, then we're stuck in a state until we can satisfy the transition condition of detecting a next transition
I'm also puzzling over:

    o  [DIVERSION_NOTIFIED]: meaning that there have been no missed
       diversions.
<Ranjit>actually, "notifications or diversions" are not missed due to all diversions matching filters

    o  [DIVERSION_DETECTED]: meaning that there have been some missed
       diversions.
<Ranjit>actually, "notifications or diversions" are missed due to diversions having failed to match any filters

I don't get how that would work. It isn't going to report the missing of 
diversions that occurred prior to the subscribe, because the 
subscription always starts in the IDLE state. 
<Ranjit> Correct

And I don't know how you 
miss diversions after the subscription is established.
<Ranjit> see clarification. 

That's all for now.

	Thanks,
	Paul

---

From: "Avasarala, Ranjit" <[email-masked]>
Date: Mon, 24 Oct 2011 16:51:21 +0800

Hi olle

Agreed.

Regards
Ranjit

From: [email-masked] [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: Friday, October 21, 2011 1:39 AM
To: [email-masked]
Subject: Re: [dispatch] New Version I-D draft-avasarala-dispatch-comm-div-notification-08.txt

Nitpicking, but anyway:

   Section 8.1.2<http://tools.ietf.org/html/draft-avasarala-dispatch-comm-div-notification-08#section-8.1.2> only.  The Content-Type header field MUST be set to

"

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Oct 2011 17:13:19 -0400

Inline

On 10/24/11 4:50 AM, Avasarala, Ranjit wrote:
> Hi Paul
>
> My comments inline<Ranjit>
>
> Regards
> Ranjit
>
>

> <Ranjit>  I am okay requiring the support for filters in the notifier

OK. That is simpler and cleaner.

>      +------------+  Diversion  +---------------+

I was assuming that if no filter is present, then there is no filtering 
- everything is selected for notification. (Otherwise it is a query 
rather than a filter.)

Do you intend that if there is no filter there will be no notifications?

Or are you expecting to return a 415 if no filter is present? It can't 
be used that way. (A missing body is not an unsupported media type.) I 
don't know of any good way to indicate that an expected body part is 
missing. You'd be better off defining *some* default behavior in the 
absence of a filter.

> <Ranjit>  well, we should transition to DIVERSION_DETECTED per "no match". The diversion did occur and was detected but no notification was sent. I would like to somehow express that the state mach…

I'm not understanding what you are trying to achieve.
But you need some state for the state machine to stall in while awaiting 
a diversion to occur. I thought that state was IDLE.

To clarify what you intend, you should enhance your diagram to include 
actions as well as states and events. And transitions should only occur 
based on events.

> <Ranjit>  yes. So, I am not sure how to address the comment but perhaps the below diagram would capture the situation?

What diagram are you referring to?

> Upon detecting the first diversion, we enter the state machine, we attempt to match filters, then we're stuck in a state until we can satisfy the transition condition of detecting a next transition
> I'm also puzzling over:
>

> <Ranjit>  see clarification.

I *thought* "missed" was referring to diversions occurring before the 
subscription was established. But I guess you mean it as diversions that 
were not requested to be notified.

If that is what you are interested in, I think you could accomplish it 
in a more straightforward way. Just have an element in the notification 
that indicates whether there have been unnotified diversions. (Or a 
count of unnotified diversions.)

	Thanks,
	Paul