IRC log of ws-ra on 2010-05-13

Timestamps are in UTC.

16:03:32 [RRSAgent]
RRSAgent has joined #ws-ra
16:03:32 [RRSAgent]
logging to http://www.w3.org/2010/05/13-ws-ra-irc
16:03:34 [trackbot]
RRSAgent, make logs public
16:03:36 [trackbot]
Zakim, this will be WSRA
16:03:37 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
16:03:37 [trackbot]
Date: 13 May 2010
16:03:38 [Zakim]
Zakim has joined #ws-ra
16:03:43 [Wu]
Wu has joined #ws-ra
16:06:07 [Bob]
rrsagent, this meeting spans midnight
16:06:30 [Ram]
Ram has joined #ws-ra
16:07:22 [Dug]
Dug has joined #ws-ra
16:08:07 [Dug]
can anyone hear us?
16:08:52 [Zakim]
+Yves
16:09:01 [asoldano]
Dug, let me try dialing again... did not hear anybody before
16:09:16 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
16:09:27 [Zakim]
+asoldano
16:11:43 [Ram]
Ram: What would the service do when it receives a GetMetadata request that contains a content type that the service does not understand?
16:12:41 [Ram]
Doug to argue our position one more time.
16:12:43 [Ram]
q+
16:12:53 [Ram]
q-
16:14:11 [Ram]
Dug: To Ram's question, the service will return nothing.
16:14:59 [Ram]
ACTION Dug will respond to Antoine's question on issue 9700 disposition.
16:14:59 [trackbot]
Created ACTION-162 - Will respond to Antoine's question on issue 9700 disposition. [on Doug Davis - due 2010-05-20].
16:15:21 [Bob]
agenda: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0043.html
16:15:45 [gpilz]
gpilz has joined #ws-ra
16:16:35 [asoldano]
q+
16:17:57 [gpilz]
SCRIBE: gpilz
16:18:19 [gpilz]
TOPIC: interop implementation table
16:18:31 [gpilz]
Bob: Red Hat is interested in WS-Eventing?
16:19:03 [gpilz]
Alession: I need to talk to Mark
16:19:14 [gpilz]
Bob: Do you have a date when you will have a complete answer?
16:19:19 [gpilz]
Alessio: No.
16:19:38 [gpilz]
(misc. back and forth about details of Red Hats interest)
16:20:16 [gpilz]
(results recorded in table)
16:20:41 [gpilz]
Ram: Paul from WSO2 has participated in this group in the past
16:20:47 [gpilz]
... he may be a potential
16:21:03 [gpilz]
ACTION: Bob ping WSO2 about participating in interop testing
16:21:03 [trackbot]
Created ACTION-163 - Ping WSO2 about participating in interop testing [on Bob Natale - due 2010-05-20].
16:22:16 [gpilz]
RESOLUTION: minutes from 2010-05-12 approved with modifications as discussed
16:22:37 [gpilz]
TOPIC: issue 9610
16:23:02 [gpilz]
(misc. recap of where we are)
16:23:13 [gpilz]
Wu: we are ok with closing this with no action
16:23:26 [gpilz]
... this is major work and we don't see the value
16:23:40 [gpilz]
... this involves changes in implementation to the Subscription Manager
16:23:53 [Tom_Rutt]
q+
16:23:54 [gpilz]
... with little increase in value
16:24:11 [asoldano]
q-
16:24:29 [gpilz]
Bob: Josh has said that this will meet his needs
16:24:29 [Bob]
ack t
16:24:36 [gpilz]
Tom: I think this is an important feature
16:24:40 [Tom_Rutt]
There was a major telecom disaster in New York city (http://en.wikipedia.org/wiki/33_Thomas_Street )
16:24:50 [gpilz]
... it will be widely used and should be supported as an optional feature
16:24:59 [Tom_Rutt]
16:25:01 [Tom_Rutt]
On September 17, 1991, management failure, power equipment failure, and human error
16:25:03 [Tom_Rutt]
combined to completely disable AT&T's central office switch at 33 Thomas. As a result,
16:25:04 [Tom_Rutt]
over 5 million calls were blocked, and Federal Aviation Administration private lines were
16:25:06 [Tom_Rutt]
also interrupted, disrupting air traffic control to 398 airports serving most of the
16:25:07 [Tom_Rutt]
northeastern United States. Because the building was designed to be self sufficient,
16:25:09 [Tom_Rutt]
AT&T had a load shedding agreement with the electric utility, Consolidated Edison,
16:25:10 [Tom_Rutt]
where they would voluntarily switch from utility power to on-site generators on request.
16:25:12 [Tom_Rutt]
This was a routine procedure that had been performed successfully in the past, but on this
16:25:13 [Tom_Rutt]
occasion, it went horribly wrong. After switching power sources, standard procedure was
16:25:15 [Tom_Rutt]
to check all the equipment power supplies, known as DC plants, for problems. But due to
16:25:16 [Tom_Rutt]
scheduled training, the check was not performed, and one plant went on battery backup.
16:25:18 [Tom_Rutt]
The alarms were not detected until it was too late to maintain uninterrupted power
16:25:19 [Tom_Rutt]
16:25:59 [gpilz]
q+
16:26:05 [Dug]
q+
16:26:41 [gpilz]
Tom: if the Sub Manager can stop a subscription (Unsubscribe) it shouldn't have any problem causing the verify event to be sent
16:27:19 [gpilz]
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?
16:27:38 [gpilz]
Tom: it's important that the client (event source) be able to determine that the channel is working
16:27:43 [Dug]
q-
16:27:48 [gpilz]
... heartbeat does this, but it is overkill
16:27:54 [Bob]
ack g
16:30:02 [gpilz]
(misc. discsussion of "separate request" or "option on GetStatus")
16:30:29 [gpilz]
Tom: if we make it an option of GetStatus, we can't re-use the wsa:ActionNotSupported
16:31:19 [Yves]
so what is really needed, a GetStatus on the manager, or verifying that events are going through the event source?
16:32:10 [gpilz]
Gil: you don't need a fault, just an indication in GetStatusResponse that the verify notification was sent or not-sent
16:32:58 [gpilz]
Gil: suggest we put together a new proposal over lunch
16:33:07 [gpilz]
Bob: Wu, would you support this?
16:33:13 [gpilz]
Wu: (yes)
16:33:25 [gpilz]
Bob: we have a conceptual consensus
16:33:37 [gpilz]
TOPIC: 9702
16:33:37 [Ram]
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702
16:33:57 [Dug]
q+
16:34:55 [gpilz]
Ram: (discusses latest proposal in comment #4)
16:35:12 [gpilz]
Bob: I have a feeling that the fault will be generated often
16:35:38 [gpilz]
q+
16:35:55 [Bob]
ack d
16:36:02 [Bob]
ack g
16:36:19 [gpilz]
Doug: my concern with adding the @exact flag is that this heads us down the slope of adding @min, @max, etc.
16:36:29 [gpilz]
... "hints" mean different things to different people
16:36:42 [gpilz]
... there's no interop around a "hint"
16:37:00 [gpilz]
... if we add back in @exact, that puts us back to where we are today
16:37:10 [Bob]
q+
16:37:12 [Ram]
q+
16:37:35 [gpilz]
Bob: going back to the original complaint; "how do you compare all these time times?"
16:37:45 [gpilz]
... wasn't that the fundamental problem?
16:38:08 [gpilz]
... wouldn't it make sense to give them a duration expressed as a long int "number of seconds"?
16:38:14 [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
16:38:32 [Bob]
ack b
16:39:52 [Tom_Rutt]
q+
16:41:15 [Bob]
ack r
16:41:43 [gpilz]
Gil: willing to live with making "Expires" server optional if we simplify it by getting rid of @min, @max, etc.
16:42:05 [gpilz]
... don't like making it server optional and keeping complicated things like @exact
16:42:15 [gpilz]
Ram: (describes use cases)
16:43:40 [gpilz]
... our experience in implementing Windows shows that the ability to hint is a valuable thing
16:44:26 [gpilz]
Wu: yesterday we had 2 options service doesn't support Expires, server supports, no-hint
16:45:15 [gpilz]
Ram: (explains proposal in comment #4)
16:45:40 [Wu]
q+
16:46:20 [Bob]
ack t
16:46:23 [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
16:46:25 [Tom_Rutt]
The time interval is specified in the following form "PnYnMnDTnHnMnS" where:
16:46:26 [Tom_Rutt]
P indicates the period (required)
16:46:28 [Tom_Rutt]
nY indicates the number of years
16:46:29 [Tom_Rutt]
nM indicates the number of months
16:46:31 [Tom_Rutt]
nD indicates the number of days
16:46:32 [Tom_Rutt]
T indicates the start of a time section (required if you are going to specify hours, minutes, or seconds)
16:46:34 [Tom_Rutt]
nH indicates the number of hours
16:46:35 [Tom_Rutt]
nM indicates the number of minutes
16:46:37 [Tom_Rutt]
nS indicates the number of seconds
16:46:38 [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
16:46:40 [Tom_Rutt]
exception
16:46:42 [Tom_Rutt]
This would accommodate event sources with timers but not clocks
16:46:53 [gpilz]
q+
16:48:44 [Bob]
ack w
16:49:09 [gpilz]
Wu: thinks we should continue to build on the consensus we established yesterday
16:49:23 [gpilz]
... if you support Expires there should be only one option "match or not"
16:49:38 [Dug]
q+
16:49:59 [Bob]
ack g
16:51:18 [Bob]
I am wondering about the complexity of this feature ...
16:51:25 [Dug]
Gil: server side optional, no expires==server chooses, specified==exact, specified+@hint=true -> hint
16:51:48 [Bob]
ack d
16:52:00 [gpilz]
Doug: um . . .
16:52:09 [gpilz]
... this proposal is a little nicer
16:52:32 [gpilz]
... the entire notion of "hint" is so bizarre
16:52:44 [Zakim]
-asoldano
16:52:52 [gpilz]
(misc. on the absurdity of a hint)
16:54:14 [Wu]
q+
16:55:54 [Bob]
ack w
16:56:15 [Ram]
q+
16:56:35 [gpilz]
(continue discussion around use cases proposals)
16:59:13 [Bob]
ack ram
17:03:38 [Zakim]
-Yves
17:04:01 [Ram]
q+
17:04:32 [Bob]
zakim, who is here
17:04:32 [Zakim]
Bob, you need to end that query with '?'
17:04:36 [Bob]
zakim, who is here?
17:04:36 [Zakim]
On the phone I see [Microsoft]
17:04:38 [Zakim]
On IRC I see gpilz, Tom_Rutt, Dug, Ram, Wu, Zakim, RRSAgent, Bob, asoldano, Yves, trackbot
17:05:49 [Tom_Rutt]
q+
17:07:45 [Dug]
q+
17:07:57 [Dug]
MUST just means what the GrantedExpires value is in the response
17:08:19 [Dug]
it doesn't necessarily control the internal adherence to that time
17:15:24 [Bob]
ack r
17:15:30 [Dug]
q-
17:16:17 [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”.
17:16:28 [Tom_Rutt]
q-
17:16:47 [Ram]
Gil's amendment: Add a @hint attribute to the Expires proposal.
17:20:26 [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".
17:21:02 [Dug]
ignore that
17:22:20 [Dug]
Absent == indefinite, present == exact, present + @hint=true == best effort, present/PT0S == indefinite/exact, present/PT0S+@hint=true == indefinite/best-effort
17:23:34 [Dug]
s/hint/bestEffort/g
17:28:20 [Dug]
policy: DateTimeSupported, ExpiresSupported, MaxExpires
17:29:35 [Dug]
add Fault for cases where expires is not supported
17:31:32 [asoldano]
asoldano has left #ws-ra
17:33:05 [gpilz]
(continued discussion of Expires)
17:35:23 [Ram]
q+
17:35:51 [Bob]
ack r
17:36:25 [Wu]
+1 to Doug proposal
17:38:49 [Dug]
and this applies to Renew
17:42:46 [Dug]
reoder assertions so they're grouped together
17:42:55 [Dug]
s/reoder/reorder/
17:45:41 [gpilz]
Proposal is jigsawed in the chat room
17:45:55 [gpilz]
need a complete proposal to be added as a comment in the bug
17:46:05 [gpilz]
lunchtime activity for Dug
17:47:50 [Dug]
proposal in: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9702
17:48:41 [gpilz]
Bob: any objection to resolving issue with comment #5 (above)
17:49:38 [gpilz]
RESOLUTION: 9702 resolved with above proposal
17:49:58 [gpilz]
TOPIC: issue 9703
17:53:30 [gpilz]
(misc. discussion about the issue and Doug's counter-proposal to Antoine's proposal)
17:56:46 [li]
li has joined #ws-ra
18:03:02 [gpilz]
RESOLUTION: 9703 closed with no action
18:03:21 [gpilz]
ACTION: gpilz to respond to Antoine on dispensation of 9703
18:03:21 [trackbot]
Created ACTION-164 - Respond to Antoine on dispensation of 9703 [on Gilbert Pilz - due 2010-05-20].
19:03:18 [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.
19:03:39 [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. ...
19:04:19 [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.
19:10:40 [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.
19:13:37 [Wu]
s/a best effort of the event souce/a best effort/
19:23:30 [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.
19:23:38 [Dug]
This OPTIONAL attribute, when present with a value of 'true',
19:23:40 [Dug]
indicates that the event source MUST grant (make a best effort) an
19:23:41 [Dug]
expiration time that matches the specified value. Note, this attribute
19:23:43 [Dug]
is modifying the default behavior of the Expires element
19:23:44 [Dug]
that REQUIRES the event source to exactly match the requested
19:23:46 [Dug]
expiration time.
20:15:51 [Bob]
zakim, who is here?
20:15:51 [Zakim]
On the phone I see [Microsoft]
20:15:52 [Zakim]
On IRC I see li, gpilz, Tom_Rutt, Dug, Ram, Wu, Zakim, RRSAgent, Bob, Yves, trackbot
20:17:01 [gpilz]
TOPIC: 9610 (contd.)
20:17:16 [Zakim]
-[Microsoft]
20:17:17 [Zakim]
WS_WSRA()11:00AM has ended
20:17:19 [Zakim]
Attendees were [Microsoft], asoldano, Yves
20:17:37 [gpilz]
(all review proposal 2 - http://www.w3.org/Bugs/Public/attachment.cgi?id=880)
20:40:09 [Wu]
wse:GetStatus/wse:Verify - This OPTIONAL element can be used by the subscriber in its GetStatus request to require the Subscription Manager to check if Notifications can be transmitted from the event source to the event sink.
20:40:23 [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.
20:40:39 [Wu]
When wse:VerificationInitiated element is absent in the GetStatus response, the verification is NOT performed.
20:40:52 [Wu]
Any active filter for the subscription MUST NOT be applied to verification event notification.
20:41:54 [Wu]
s/to require/to request/
20:42:41 [gpilz]
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.
20:43:14 [gpilz]
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.
20:44:08 [gpilz]
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.
20:44:59 [gpilz]
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.
20:49:25 [Wu]
When wse:VerificationInitiated element is absent in the GetStatus response, the verification is NOT performed.
20:50:02 [gpilz]
The absence of this element in a GetStatusResponse indicates that no verification notification was initiated.
20:55:10 [Dug]
The presence of the VerificationInitiated element in a GetStatus response message MUST NOT be used to infer the success or failure of the delivery of the Verification event.
20:55:32 [Dug]
s/GetStatus response/GetStatusResponse/
20:56:12 [gpilz]
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.
20:57:51 [gpilz]
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.
20:58:46 [Wu]
The presence of the VerificationInitiated element in a GetStatus response message does not indicate the success of the verification.
21:08:08 [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.
21:17:53 [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.
21:23:14 [gpilz]
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
21:25:41 [gpilz]
"A value of PT0S indicates is indefinite." ?
21:26:02 [gpilz]
Bob: WS-Eventing and WS-Enum must go back to LC
21:26:15 [gpilz]
... we'll do a 3 week last call
21:27:09 [gpilz]
... between now and 5/25/2010 review resolutions to all our issues and make sure the resolutions were properly incorporated
21:27:40 [gpilz]
... if we agree that everything was properly incorporated, we can vote to go to LC again
21:29:42 [gpilz]
All: thanks to Microsoft for excellent hosting and yummy food
21:29:53 [gpilz]
All: thanks for the well functioning wireless as well
21:31:09 [Bob]
rrsagent, generate minutes
21:31:09 [RRSAgent]
I have made the request to generate http://www.w3.org/2010/05/13-ws-ra-minutes.html Bob
21:33:37 [gpilz]
gpilz has left #ws-ra