Revised proposal for 2.64

[Matthew I Roberts <matt.roberts@uk.ibm.com>]

As we discussed on the last conference
call (30 Jan, from minutes);
  "Agreed to refine proposal
to do roman numeral i & iii, defering iv to policy. ii will not be
done.
  Matt to consolidate into a formal
proposal."

I have revised the proposal as below.
Thanks,

Matt


Matt Roberts
IBM WebSphere Messaging Design and Development
Hursley Park, England. +44 1962 815444
matt.roberts@uk.ibm.com
MP 211 / DE3H22

=======================================================================================
Ref: Original proposal;
http://www.oasis-open.org/apps/org/workgroup/wsn/email/archives/200601/msg00011.html


The options under discussed (for reference)
are as follows;
i) A constant string (as specified
in part 1 of the proposal above)
ii) A URI string that reflects the
topic name
iii) Administrative configuration in
the topic namespace document
iv) Policy extension to allow the Subscriber
application to nominate the action URI


NOTE: In proposals 2 and 3 I would
like to directly reuse the same elements and definitions, which means using
the wstop namespace in the SubscriptionPolicy (as noted in proposal 3).
This will likely require some discussion and is best to be done ahead of
any changes so that we are agreed.


<proposal part 1 (the default behaviour,
option i)>

The NotificationProducer SHOULD utilise the same Action URI as defined for the Notify operation, except in situations where the NotificationProducer has specialist knowledge of the consuming application which would cause it to use some alternative URI.

</proposal part 1>

<proposal part 2 (option iii)>

A new is added to the wstop:Topic element that describes a standard mechanism for controlling the action URI sent with a Raw notification on a per-message-type basis. Support for this policy is optional. The behaviour described by this policy element applies only to notifications emitted for Raw subscriptions, and does not apply to notifications for wrapped subscriptions.

When using the RawActionURI element in a topic document, a wsnp:messageType element SHOULD be specified for every message type defined in the messageTypes attribute of the wstop:Topic element in which it is contained. In situations where a wsnp:messageType element is not defined for a type defined in the wstop:Topic attribute, the default URI string described in part 1 of this proposal MUST be applied to any raw notifications emitted by the producing application.

<wstop:Topic name="myTopic" messageTypes="xyz:m1 abc:m2">

  <wstop:RawActionURI>

    <wstop:messageType name="xyz:m1" action="http://example.com/myCustomActionURI"/>

    <wstop:messageType name="abc:m2" action="http://example.com/myOtherCustomActionURI"/>

  <wstop:RawActionURI>

</wstop:Topic>

A sample schema for this policy element might be as follows;

  <xsd:element name="RawActionURI">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="MessageType" minOccurs="1" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:attribute name="name" type="xsd:QName" use="required" />
            <xsd:attribute name="action" type="xsd:anyURI" use="required" />
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>      
    </xsd:complexType>
  </xsd:element>

</proposal part 2>

<proposal part 3 (option iv)>

The definition of this configuration ability is deferred to the WSN-Policy document, with the proposed text attached.

NOTE: Since this behaviour exactly mirrors the functionality provided in proposal 2 above, I would like to reuse the same definitions and elements directly. This means specifying elements from the wstop namespace in the SubscriptionPolicy, which I guess will require some discussion.

A new policy assertion section is added to the WSN Policy document that describes a standard mechanism for controlling the action URI sent with a Raw notification on a per-message-type basis. Support for this policy is optional. If the NotificationProducer does not support this policy then it should respond to the Subscribe with UnrecognisedPolicyRequestFault or UnsupportedPolicyRequestFault as appropriate.

If it does support the policy assertion then any message types that match the Subscription should be sent to the consuming application with the action URI specified in the policy configuration. If a message type is received that is not configured in the policy assertion then it reverts to the default behaviour described in part 1 of this proposal. This policy assertion has no effect if UseRaw is not specified (ie wrapped notifications are being used).

An example of how this policy might be exposed the subscribe request is as follows;

<wsnt:SubscriptionPolicy>

  <wsnt:UseRaw/>

  <wstop:RawActionURI>

    <wstop:messageType name="xyz:m1" action="http://example.com/myCustomActionURI"/>

    <wstop:messageType name="tns:m2" action="http://example.com/myOtherCustomActionURI"/>

  <wstop:RawActionURI>

</wsnt:SubscriptionPolicy>

</proposal part 2>