Web Services Resource Access Working Group Teleconference -- 13 May 2010

<trackbot> Date: 13 May 2010

<Dug> can anyone hear us?

<asoldano> Dug, let me try dialing again... did not hear anybody before

<Ram> Ram: What would the service do when it receives a GetMetadata request that contains a content type that the service does not understand?

<Ram> Doug to argue our position one more time.

<Ram> Dug: To Ram's question, the service will return nothing.

<Ram> ACTION Dug will respond to Antoine's question on issue 9700 disposition.

<trackbot> Created ACTION-162 - Will respond to Antoine's question on issue 9700 disposition. [on Doug Davis - due 2010-05-20].

<scribe> SCRIBE: gpilz

interop implementation table

Bob: Red Hat is interested in WS-Eventing?

Alession: I need to talk to Mark

Bob: Do you have a date when you will have a complete answer?

Alessio: No.

(misc. back and forth about details of Red Hats interest)

(results recorded in table)

Ram: Paul from WSO2 has participated in this group in the past
... he may be a potential

<scribe> ACTION: Bob ping WSO2 about participating in interop testing [recorded in http://www.w3.org/2010/05/13-ws-ra-minutes.html#action01]

<trackbot> Created ACTION-163 - Ping WSO2 about participating in interop testing [on Bob Natale - due 2010-05-20].

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

Bob: Josh has said that this will meet his needs

Tom: I think this is an important feature

<Tom_Rutt> There was a major telecom disaster in New York city (http://en.wikipedia.org/wiki/33_Thomas_Street )

Tom: it will be widely used and should be supported as an optional feature

<Tom_Rutt> “

<Tom_Rutt> On September 17, 1991, management failure, power equipment failure, and human error

<Tom_Rutt> combined to completely disable AT&T's central office switch at 33 Thomas. As a result,

<Tom_Rutt> over 5 million calls were blocked, and Federal Aviation Administration private lines were

<Tom_Rutt> also interrupted, disrupting air traffic control to 398 airports serving most of the

<Tom_Rutt> northeastern United States. Because the building was designed to be self sufficient,

<Tom_Rutt> AT&T had a load shedding agreement with the electric utility, Consolidated Edison,

<Tom_Rutt> where they would voluntarily switch from utility power to on-site generators on request.

<Tom_Rutt> This was a routine procedure that had been performed successfully in the past, but on this

<Tom_Rutt> occasion, it went horribly wrong. After switching power sources, standard procedure was

<Tom_Rutt> to check all the equipment power supplies, known as DC plants, for problems. But due to

<Tom_Rutt> scheduled training, the check was not performed, and one plant went on battery backup.

<Tom_Rutt> The alarms were not detected until it was too late to maintain uninterrupted power

<Tom_Rutt> “

Tom: if the Sub Manager can stop a subscription (Unsubscribe) it shouldn't have any problem causing the verify event to be sent

Doug: is it important that the client be able to ask for these verify messages, or is it sufficient for the Event Source to be able to send it and the client can send it by choosing the right filter?

Tom: it's important that the client (event source) be able to determine that the channel is working
... heartbeat does this, but it is overkill

(misc. discsussion of "separate request" or "option on GetStatus")

Tom: if we make it an option of GetStatus, we can't re-use the wsa:ActionNotSupported

<Yves> so what is really needed, a GetStatus on the manager, or verifying that events are going through the event source?

Gil: you don't need a fault, just an indication in GetStatusResponse that the verify notification was sent or not-sent
... suggest we put together a new proposal over lunch

Bob: Wu, would you support this?

Wu: (yes)

Bob: we have a conceptual consensus

9702

<Ram> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702

Ram: (discusses latest proposal in comment #4)

Bob: I have a feeling that the fault will be generated often

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"

<Bob> I am wondering about the complexity of this feature ...

<Dug> Gil: server side optional, no expires==server chooses, specified==exact, specified+@bestEffort=true -> bestEffort

Doug: um . . .
... this proposal is a little nicer
... the entire notion of "bestEffort" is so bizarre

(misc. on the absurdity of a bestEffort)

(continue discussion around use cases proposals)

<Dug> MUST just means what the GrantedExpires value is in the response

<Dug> it doesn't necessarily control the internal adherence to that time

<Ram> Dug's original proposal: “Expires is server optional, add a fault for when its not, add a ExpiresSupported policy assertion, Subscribe w/o Expires == server chooses, Subscribe + Expires == match the time/duration or fault”.

<Ram> Gil's amendment: Add a @bestEffort attribute to the Expires proposal.

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

<Dug> ignore that

<Dug> Absent == indefinite, present == exact, present + @bestEffort=true == best effort, present/PT0S == indefinite/exact, present/PT0S+@bestEffort=true == indefinite/best-effort

<Dug> policy: DateTimeSupported, ExpiresSupported, MaxExpires

<Dug> add Fault for cases where expires is not supported

<scribe> (continued discussion of Expires)

<Wu> +1 to Doug proposal

<Dug> and this applies to Renew

<Dug> reorder assertions so they're grouped together

Proposal is jigsawed in the chat room

need a complete proposal to be added as a comment in the bug

lunchtime activity for Dug

<Dug> proposal in: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702

Bob: any objection to resolving issue with comment #5 (above)

RESOLUTION: 9702 resolved with above proposal

issue 9703

(misc. discussion about the issue and Doug's counter-proposal to Antoine's proposal)

RESOLUTION: 9703 closed with no action

<scribe> ACTION: gpilz to respond to Antoine on dispensation of 9703 [recorded in http://www.w3.org/2010/05/13-ws-ra-minutes.html#action02]

<trackbot> Created ACTION-164 - Respond to Antoine on dispensation of 9703 [on Gilbert Pilz - due 2010-05-20].

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

(all review proposal 2 - http://www.w3.org/Bugs/Public/attachment.cgi?id=880)

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

RESOLUTION: issue 9610 resolved with proposal 5 (http://www.w3.org/Bugs/Public/attachment.cgi?id=883) fix "Verify operation" in first sentence Appendix B; remove "pseudo" from Appendix B

"A value of PT0S indicates is indefinite." ?

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

- DRAFT -

Web Services Resource Access Working Group Teleconference

13 May 2010

Attendees

Contents

interop implementation table

issue 9610

9702

issue 9703

9610 (contd.)

Summary of Action Items

Scribe.perl diagnostic output