Inference of Baseline Policy Behaviors

["Patil, Sanjay" <sanjay.patil@sap.com>]

This is regarding the AI I took on the Apr 11 conf call -
AI 75 - Issue 2.36: Sanjay to investigate whether BaseN adequately
implies the stated defaults.
(Rick posted the baseline policy behaviour by email)

I went through the wsn-WS-BaseNotification-1[2].3-draft-01e.doc document
and here are my findings (tagged with "<sanjay>" in the text cut-pasted
from Rick's baseline policy behavior email).

Thanks,
Sanjay

-------------------------------------------------------------------
Durability (issue 2.28):
	1. No subscription durability
<sanjay> I am assuming that this policy is about the behavior of
NotificationProducer in handling messages in between the pause and the
resume of a Subscription. The specification outlines the various options
available (lines 920-930), but it is not clear what the baseline
behavior is.</sanjay>

	2. No message durability
<sanjay> I am assuming that this policy is about the behavior of
NotificationProducer in handling messages for which the
NotificationConsumer is currently not available, that is, whether the
NotificationProducer should persist the messages for which a
can-not-be-delivered exception was raised by the message delivery layer.
The specification currently does not seem to discuss this issue
sufficiently and therefore concerning baseline behavior may not be clear
to a reader.</sanjay>

Pull Notification:
	1. No pull notification
<sanjay>The version wsn-WS-BaseNotification-1[2].3-draft-01e.doc does
not describe the requirement/solution for Pull Notification. Need to
revisit once the updates have been made.</sanjay>

Continuity:
	1. Subscription change is the same as delete/add (messages may
be missed)
<sanjay>Lines 813-815 recommend that those NotificationProducers that
are capable of providing stronger guarantees of continuity SHOULD
advertise the same as a policy assertion. However the baseline behavior
in absence of any such policy statements is not very clear, IMHO. We
should perhaps tighten up the language a bit more.</sanjay>

Flow Control / Message rate limiting
	1. No flow control 
	2. No priority scheme
<sanjay> I do not find any discussion of these issues in the
specification and therefore it is hard to say what the reader's
interpretation of concerning baseline behavior will be. </sanjay>

Reliability
	1. No reliable messaging mechanism
<sanjay> One would assume that the description of
NotificationConsumer.Notify() operation would discuss this issue and
clarify what the baseline behavior would be. I was not able to locate
any such text.</sanjay>
---------------------------------------------------------------------