Second item first (strawmen for multiple subscriptions, life
cycles, etc.)
I believe there are basically two choices to be made for the semantics
of a pull point newly created by an NP:
- Whether the pull point MUST be usable by any NP (and so must
support the interfaces required of a NotificationConsumer in a
meaningful way), or whether it's sufficient that the NP that created it
knows what to do with it.
- Whether the pull point MUST be usable in any number of
subscriptions, at least one subscription, or possibly not at all (e.g.,
the pull point reaches its scheduled termination time before anyone
does anything with it).
The clear default choices, on the basis of "assume nothing" appear to be
- NOT REQUIRED to be usable by other NPs
- NOT REQUIRED to be usable in any further subscriptions
Obviously, this doesn't require anything useful at all, so 2 should
probably read:
- NOT REQUIRED to be usable in any further subscriptions, but
SHOULD work in at least one.
Cases like scheduled termination and server restart are good reasons to
say SHOULD instead of MUST. Given that no subscriptions are required
to be made (even without scheduled termination or server restart, the
Subscriber that requested the pull point might also change its mind and
not subscribe), we can't make an unconditional statement about the
relationship between pull points and subscriptions. Under the "assume
nothing" guideline, we shouldn't try to make such statements anyway.
Come to think of it, an NP can reject any subscription it likes, for
any reason or no reason at all, so it can certainly refuse to use a
pull point in more than one subscription.
Note that entities other than NPs can produce pull points, in which
case they SHOULD -- pretty well MUST, really -- be usable by other NPs,
but I don't think we need to take this on.
First item second (make text neutral with regard to "cookie" style)
Add the following text after line 861, as per the above:
It is expected that in many cases, a NotificationProducer
will support the CreatePullPoint interface in order to create pull
points for use by its own subscribers. In such cases, the created pull
point is NOT REQUIRED to be a valid ConsumerReference for any other
NotificationProducer. [Note: This relies somewhat on the interpretation
of the MAY clause in section 3 discussed previously]
While it is possible and in some cases useful to use the same
NotificationConsumer in multiple subscriptions, a NotificationProducer
is NOT REQUIRED to accept a pull point in more than one subscription
request, or in any subscription requests at all, just as it is not
required to accept any other ConsumerReference.
Similarly, a NotificationProducer is NOT REQUIRED to cancel a
subscription in the event that its NotificationConsumer is destroyed,
nor to attempt to destroy its NotificationConsumer when a subscription
is destroyed, whether or not the NotificationConsumer in question is a
pull point.
Add the following text after the sentence ending "... 'wrappered'
approach." on line 875, regarding Notification formats:
In cases where the NotificationConsumer of a Subscription
is a pull point created by the same NotificationProducer that created
the subscription, it is not meaningful to distinguish between "raw" and
"wrappered" format, as the messages will only be seen through the
GetMessages method of the pull point. In such cases, either format may
be assumed, as the result is the same in either case.
Amend the sentence following this insertion (on lines 875-6) to read:
By
default, Notification Messages received by the
PullPoint
through its NotificationConsumer interface are
accumulated by the PullPoint on
a best effort basis.
Amend the last sentence of the paragraph (on lines 880-1) to read:
The
PullPoint interface does not define additional
constraints on the accumulation of messages its use
of the NotificationConsumer interface.
Finally, we may wish to amend the description of
/wsnt:GetMessagesResponse/wsnt:NotificationMessage on lines 926-36 to
re-emphasize that the raw/wrappered distinction only makes sense for
externally produced pull points, but this is not strictly necessary
given the above.
|