RESOLUTION: minutes
from 2010-05-12 approved with modifications as
discussed

issue 9610

(misc. recap of where we are)

Wu: we are ok with closing this with
no action
... this is major work and we don't see the value
... this involves changes in implementation to the Subscription
Manager
... with little increase in value

9702

Doug: my concern with adding the
@exact flag is that this heads us down the slope of adding @min,
@max, etc.
... "bestEfforts" mean different things to different people
... there's no interop around a "bestEffort"
... if we add back in @exact, that puts us back to where we are
today

Bob: going back to the original
complaint; "how do you compare all these time times?"
... wasn't that the fundamental problem?
... wouldn't it make sense to give them a duration expressed as a
long int "number of seconds"?

<Wu> Topic 9610 (verify): It will
be an optional attribute in GetStatus. The response from GetStatus
indicates whether verify is supported or not. If supported, the
verify event will be fired from event source to event sink

Gil: willing to live with making
"Expires" server optional if we simplify it by getting rid of @min,
@max, etc.
... don't like making it server optional and keeping complicated
things like @exact

Ram: (describes use cases)
... our experience in implementing Windows shows that the ability
to bestEffort is a valuable thing

Wu: yesterday we had 2 options
service doesn't support Expires, server supports, no-bestEffort

Ram: (explains proposal in comment
#4)

<Tom_Rutt> The duration data type
is used to specify a time interval. I could accept just allowing
the duration type for expiry time, with "exact" semantics

<Tom_Rutt> The time interval is
specified in the following form "PnYnMnDTnHnMnS" where:

<Tom_Rutt> P indicates the period
(required)

<Tom_Rutt> nY indicates the
number of years

<Tom_Rutt> nM indicates the
number of months

<Tom_Rutt> nD indicates the
number of days

<Tom_Rutt> T indicates the start
of a time section (required if you are going to specify hours,
minutes, or seconds)

<Tom_Rutt> nH indicates the
number of hours

<Tom_Rutt> nM indicates the
number of minutes

<Tom_Rutt> nS indicates the
number of seconds

<Tom_Rutt> A profile could
specify that the Client use a subset of the above duration units
(e.g, days, hours, minutes, seconds), to simplify calculations and
comparisons There could be a time unit not supported

<Tom_Rutt> exception

<Tom_Rutt> This would accommodate
event sources with timers but not clocks

Wu: thinks we should continue to
build on the consensus we established yesterday
... if you support Expires there should be only one option "match
or not"

<Dug> RM: This element, if
present, of type xs:duration specifies the RM Source's requested
duration for the Sequence. The RM Destination MAY either accept the
requested duration or assign a lesser value of its choosing. A
value of "PT0S" indicates that the Sequence will never expire.
Absence of the element indicates an implied value of "PT0S".

<Wu>
[Body]/wse:Subscribe/wse:Expires - This OPTIONAL element can be
used by the subscriber to indicate the expiration time of the
requested subscription. If this element is not present, the implied
default expiry time is indefinite (or no expiry). A value of PT0S
indicates no expiry.

<Wu> If the event source does not
support wse:Expire element present in a Subscribe request message
then a wse:ExpiresNotSupported fault MUST be generated. ...

<Wu>
[Body]/wse:Subscribe/wse:Expires@BestEffort - This OPTIONAL
attribute, when present with a value of 'true', indicates that the
event source MAY choose an expiry time that best matches the
requested expiry time.

<Wu> How about this:
[Body]/wse:Subscribe/wse:Expires@BestEffort - This OPTIONAL
attribute, when present with a value of 'true', indicates that the
event source SHOULD choose an expiration time that is a best effort
of the event source to match the expiration time request.

<Wu> s/a best effort of the event
souce/a best effort/

<Wu> wse:Expires@BestEffort -
This OPTIONAL attribute, when present with a value of 'true',
indicates that the event source SHOULD grant an expiration time
that is a best effort of the event source to match the requested
expiration time. Default value of this attribute is "false" in
which the event source MUST grant the requested expiration time or
fault the subscription request.

<Dug> This OPTIONAL attribute,
when present with a value of 'true',

<Dug> indicates that the event
source MUST grant (make a best effort) an

<Dug> expiration time that
matches the specified value. Note, this attribute

<Dug> is modifying the default
behavior of the Expires element

<Dug> that REQUIRES the event
source to exactly match the requested

<Dug> expiration time.

9610 (contd.)

<Wu> wse:GetStatus/wse:Verify -
This OPTIONAL element can be used by the subscriber in its
GetStatus request to request the Subscription Manager to check if
Notifications can be transmitted from the event source to the event
sink.

<Wu> If event source opts to
support the wse:Verify request, it MUST include
wse:VerificationInitiated element in its GetStatus response, and it
MUST send a single verification event notification, defined in
Appendix B, from the event source to the event sink.

<Wu> When
wse:VerificationInitiated element is absent in the GetStatus
response, the verification is NOT performed.

<Wu> Any active filter for the
subscription MUST NOT be applied to verification event
notification.

This OPTIONAL element can be used by the
subscriber in its GetStatus request to petition the Subscription
Manager to check if Notifications can be transmitted from the event
source to the event sink.

This OPTIONAL element can be used by the
subscriber in its GetStatus request to ask the Subscription Manager
to verify if Notifications can be transmitted from the event source
to the event sink.

This OPTIONAL element can be used by the
subscriber in its GetStatus request to ask the Subscription Manager
to verify that Notifications can be transmitted from the event
source to the event sink.

If the subscription manager opts to support the
wse:Verify request, it MUST include a wse:VerificationInitiated
element in its GetStatus response, and it MUST cause the event
source to transmit a single verification event notification,
defined in Appendix B, from the event source to the event sink.

<Wu> When
wse:VerificationInitiated element is absent in the GetStatus
response, the verification is NOT performed.

The absence of this element in a GetStatusResponse
indicates that no verification notification was initiated.

<Dug> The presence of the
VerificationInitiated element in a GetStatusResponse message MUST
NOT be used to infer the success or failure of the delivery of the
Verification event.

The presence of the VerificationInitiated element
in a GetStatus response message does not indicate the success or
failure of the delivery of the verification notification.

The presence of the VerificationInitiated element
in a GetStatus response message does not indicate the success or
failure of the delivery of the verification event.

<Wu> The presence of the
VerificationInitiated element in a GetStatus response message does
not indicate the success of the verification.

<Dug> .... it MUST cause the
event source to attempt to transmit a notification, containing only
a single verification event as defined in Appendix B, from the
event source to the event sink.

<Wu> wse:VerificationInitiated -
This element MUST NOT appear in the GetStatusResponse unless the
corresponding GetStatus request contained the wse:Verify element.
The presence of wse:VerificationIntiated in the GetStatus response
indicates the wse:Verify request is honored. The absence of this
element in a GetStatusResponse indicates that verification was not
initiated.

Bob: WS-Eventing and WS-Enum must go
back to LC
... we'll do a 3 week last call
... between now and 5/25/2010 review resolutions to all our issues
and make sure the resolutions were properly incorporated
... if we agree that everything was properly incorporated, we can
vote to go to LC again

All: thanks to Microsoft for
excellent hosting and yummy food
... thanks for the well functioning wireless as well