Re: [wsn] Remaining work, especially WSN 2.62

[Peter Niblett <peter_niblett@uk.ibm.com>]

David


You have invited some comments on your proposal, so in the absence of any
others, here are some from me..



1. I think the flexibility you are suggesting in the third paragraph is
going too far (in effect it is saying a Producer MAY produced raw message
even if the wsnt:useRaw is absent). Suppose I am a Consumer who follows the
rules you lay down (I obey the SHOULD and implement the Notify message) and
I then subscribe to an NP that behaves in this way. My subscription would
apparently be accepted - I would a normal subscriptionResponse back instead
of a fault, yet I would never see any NotificationMessages as they would
all come in with the wrong [action].

It also conflicts with the text at the start of section 3 (lines 287-289)
in draft 02d which say


"When a Subscriber sends a Subscribe request message, it indicates which
form of Notification is required (the raw Notification, or the Notify
Message). The NotificationProducer MUST observe this component of the
Subscription and use the form that has been requested."


 I suggest you change the paragraph to say that the NP MUST return a fault
if the element is present and the NP doesn't support Notify



2. We do need to state whether the UnrecognizedPolicyRequestFault is a MUST
or a MAY, i.e. whether we require every NP to reject all policies it
doesn't recognize, or whether some NPs are allowed to ignore unrecognized
policies (the fact that we are defining a Fault suggests that we think that
some NPs might want to fault). Also we should probably state somewhere that
all NPs must recognize the useRaw policy.



3. In the second para you say that the wsnt:UseRaw MUST appear in the fault
detail, but in the 02d description of the UnsupportedPolicyRequestFault you
say

·     The detail element of this fault MAY contain elements representing
the offending policy requests.


I think we should either make all policy details optional in this fault, or
all policy details mandatory (I don't really mind which), but we currently
only have one policy, and I'm unhappy with a spec where onse sentence
overrides another in 100% of the cases.



4. A minor comment on the second paragraph. I don't think the first
sentence "If this element is present and the NotificationProducer supports
raw notification, then the NotificationProducer MUST produce the raw
Notification itself" adds anything over and above the first paragraph, and
the word "itself" is a bit ambiguous. I suggest you remove it, and replace
the entire paragraph with:

"If this element is present and the NotificationProducer does not support
raw notification, then the NotificationProducer MUST return an
UnsupportedPolicyRequestFault message with a wsnt:UseRaw element as a child
of the fault detail."

You could add a sentence saying that the NC SHOULD implement the
appropriate raw message (similar to the requirement on the NC to implement
the Notify message that appears in the 3rd para).



5. For symmetry with 4, I would suggest removing the first sentence of the
third paragraph




                                                                       
             David Hull                                                
             <dmh@tibco.com>                                           
                                                                        To
             12/10/2005 06:22          wsn@lists.oasis-open.org        
                                                                        cc
                                                                       
                                                                   Subject
                                       [wsn] Remaining work, especially
                                       WSN 2.62                        
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




I believe I have executed on all the remaining work.  Whether correctly or
not is a different question.  In particular, here is the crucial text for
the UseRaw element in  the resolution of 2.62 (there are also some changes
concerning faults, both in the text and in the XSD/WSDL):


      An element whose presence indicates that the NotificationProducer is
      to produce Notifications without using the wsnt:Notify wrapper. This
      element SHOULD NOT occur more than once in a Subscribe request
      message, as only its presence or absence is significant.


      If this element is present and the NotificationProducer supports raw
      notification, then the NotificationProducer MUST produce the raw
      Notification itself.   If the NotificationProducer does not support
      raw notification, it MUST return a UnsupportedPolicyRequestFault
      message with a wsnt:UseRaw element as a child of the fault detail.


      If this element is not present and the NotificationProducer supports
      the wsnt:Notify wrapper, then the NotificationProducer SHOULD use the
      wsnt:Notify message in Notifications produced for this subscription,
      and the NotificationConsumer referred to in the
      wsnt:ConsumerReference element SHOULD implement the Notify message
      and include a Notify operation in its portType definition.  If the
      element is not present and the NotificationProducer does not support
      the wsnt:Notify wrapper, it SHOULD return a
      NotifyMessageNotSupportedFault message.  This behavior may be
      overridden by the presence of other policy-related information.


The idea is that if UseRaw is present, the subscriber definitely wanted
that behavior, and the NP MUST either provide it or complain that it can't.
If UseRaw is not present, the default assumption is that the subscriber
meant Notify, but this assumption may be overridden through other means.
E.g., an implementor might say "My implementation uses MyNotify by
default."  This may not be a good idea -- one reason I wanted to
double-check.

What the text above doesn't quite say, and maybe we should somewhere, is
that policy handling essentially consists of these steps:
      Figure out if you even know about all the policies.  If not, you MAY
      fault (with an UnrecognizedPolicyRequestFault)  Or do we assume that
      you can safely ignore what you don't understand?  Or we introduce
      some sort of mustUnderstand?
      Assuming you understand all the policies, or don't mind not
      understanding, figure out which of those you support.  You MUST
      (MAY?) fault on requests for policies you know about but don't
      support (with an UnsupportedPolicyRequestFault).  This could happen
      if, say, support for a policy has been disabled by configuration, or
      if not all subscribers are allowed to use all policies.  UseRaw is a
      special case of this: we assume everyone recognizes it but maybe not
      everyone supports it.
      If some recognized and supported policy is used in an invalid way,
      you MAY fault (with a SubscribeCreationFailedFault -- which sounds a
      bit ungrammatical to me, but so be it).
Obviously, all this is involved enough to merit a bit of review.