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.
|