IRC log of ws-ra on 2009-05-12

Timestamps are in UTC.

19:27:29 [RRSAgent]
RRSAgent has joined #ws-ra
19:27:29 [RRSAgent]
logging to
19:27:31 [trackbot]
RRSAgent, make logs public
19:27:31 [Zakim]
Zakim has joined #ws-ra
19:27:33 [trackbot]
Zakim, this will be WSRA
19:27:33 [Zakim]
ok, trackbot, I see WS_WSRA()3:30PM already started
19:27:34 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
19:27:34 [trackbot]
Date: 12 May 2009
19:27:54 [Zakim]
19:27:54 [marklittle]
marklittle has joined #ws-ra
19:28:22 [Bob]
zakim, [Micro is Geoff
19:28:22 [Zakim]
+Geoff; got it
19:28:30 [Bob]
zakim, geoff has asir
19:28:30 [Zakim]
+asir; got it
19:28:45 [dug]
dug has joined #ws-ra
19:28:55 [Zakim]
19:29:11 [Zakim]
19:29:19 [Bob]
scribe: Miar Little
19:29:29 [Zakim]
19:29:36 [Bob]
scribe: Mark Little
19:29:55 [Bob]
zakim, [ib is doug
19:29:55 [Zakim]
+doug; got it
19:30:17 [Katy]
Katy has joined #ws-ra
19:30:19 [Zakim]
19:30:22 [dug]
19:31:02 [Zakim]
19:31:29 [Zakim]
+ +0125669aaaa
19:31:31 [DaveS]
DaveS has joined #ws-ra
19:31:41 [Bob]
zakim, ??P9 is Dave
19:31:41 [Zakim]
+Dave; got it
19:31:51 [gpilz]
gpilz has joined #ws-ra
19:31:52 [Zakim]
- +0125669aaaa
19:32:02 [Zakim]
+ +0208234aabb
19:32:24 [Ashok]
Ashok has joined #ws-ra
19:32:32 [Zakim]
+ +0208234aacc
19:32:59 [Zakim]
19:33:23 [Zakim]
19:34:52 [Zakim]
19:37:32 [Bob]
19:38:24 [marklittle]
chair: comments on agenda? none.
19:38:42 [asir]
asir has joined #ws-ra
19:38:50 [marklittle]
chair: any objections to approval minutes from May 5th? None. Accepted.
19:39:30 [marklittle]
topic: administrivia ... 26th of May to let group know about attendance at f2f.
19:39:52 [marklittle]
topic: May Snapshots
19:39:52 [Paul]
Paul has joined #ws-ra
19:40:56 [Zakim]
+ +1.571.262.aadd
19:41:21 [marklittle]
chair: has there been enough time to look at incorporated issues? Some indication that more time needed. One more week extension.
19:41:45 [marklittle]
topic: task team progress
19:42:05 [marklittle]
chair asks for status update
19:42:21 [Ashok]
Ashok has joined #ws-ra
19:42:29 [Vikas]
Vikas has joined #ws-ra
19:43:02 [marklittle]
gpilz making progress. couple of issues remaining but no main problems or disagreements at this stage.
19:43:09 [marklittle]
chair what is expected completion date?
19:43:13 [marklittle]
gpilz what's expected?
19:43:24 [marklittle]
chair closure of issue 6401.
19:43:46 [asir]
19:44:07 [marklittle]
chair resolution of 6401 direction would be sufficient so we could then work on text. Though text would be better. What is problem?
19:45:22 [Geoff]
19:46:35 [marklittle]
chair why not just forward proposal for discussion?
19:46:36 [Bob]
ack geoff
19:47:25 [marklittle]
chair will put this back on the agenda for next week. Would like to see something to discuss before then if possible.
19:47:46 [marklittle]
Wu posted already.
19:48:30 [marklittle]
chair if version posted by Wu is good enough, let's start discussions around it. Move commentary to public list.
19:48:36 [marklittle]
topic: new issues
19:49:06 [marklittle]
chair none currently.
19:50:07 [marklittle]
topic: issue 6860
19:50:18 [Bob]
19:50:18 [marklittle]
19:51:53 [marklittle]
gpilz discusses issue and asks if there are any concerns over removing wsen:EnumerationContext?
19:52:06 [marklittle]
chair everyone ok with proposal? no objections.
19:52:12 [marklittle]
resolution: 6860 resolved
19:52:36 [marklittle]
s/resolved/resolved as per bugzilla issue/p
19:52:48 [marklittle]
topic: issue 6696
19:52:55 [marklittle]
19:53:53 [gpilz]
s/and an problem is detected/and a problem is detected/
19:54:19 [Geoff]
19:54:37 [Bob]
ack geoff
19:55:14 [marklittle]
Geoff fine in general, but "If this check is performed and an problem is detected then the event source MUST generate [fault]". Only place in spec with MUST other than MAY. Why?
19:55:29 [marklittle]
dug generating is different from transmitting.
19:55:42 [li]
19:55:50 [marklittle]
Geoff should be consistent though. Either all MUST or all MAY. If former then we should raise another issue to make them all MUST.
19:55:54 [marklittle]
dug agrees.
19:55:57 [marklittle]
19:56:05 [Bob]
ack li
19:56:23 [Geoff]
19:56:35 [DaveS]
19:56:39 [marklittle]
li does MAY mean if something else went wrong you can generate this one or something else? Case of multiple errors, where this may not be the first one that you generate.
19:57:06 [marklittle]
dug not sure, but he suspects the spec is silent on the case of multiple faults. Implementation choice. MUST or MAY wouldn't change that aspect of the spec.
19:57:17 [Bob]
ack geo
19:57:44 [marklittle]
Geoff it says it "SHOULD have some cursory validity" But maybe MAY?
19:58:07 [marklittle]
dug prefers SHOULD as it's a recommendation. Pious advice is better.
19:58:12 [Bob]
ack dave
19:59:01 [marklittle]
DaveS the fault raising is InvalidEPR. Is there anything people may check that could make this a confusing fault? Such that if it fails it could be a valid EPR but could get back an InvalidEPR fault because of this.
19:59:16 [Zakim]
19:59:31 [marklittle]
dug UnsupportedEPR?
19:59:59 [marklittle]
DaveS limit it to checking semantic validity of EPR then it's accurate as InvalidEPR.
20:00:18 [marklittle]
chair change InvalidEPR to UnusableEPR?
20:01:07 [gpilz]
For example, an unsupported transport specified within the wsa:Address IRI.
20:01:18 [Geoff]
20:01:26 [Bob]
ack geo
20:01:43 [marklittle]
Geoff any way we can be more specific what cursory validity checking means? Seems vague.
20:01:58 [gpilz]
20:02:04 [marklittle]
dug yes, that's deliberate. Didn't want to be specific. Leave it to the implementation so they can choose what they can check.
20:02:38 [marklittle]
dug open to stronger wording if we can agree on it.
20:02:57 [marklittle]
Geoff would prefer some stronger wording. Just not sure what that is.
20:03:06 [marklittle]
dug maybe a separate issue? So we can close this one?
20:03:11 [gpilz]
20:03:19 [marklittle]
Geoff yes, will create another issue later.
20:03:24 [gpilz]
20:04:17 [Bob]
ack gpi
20:05:19 [marklittle]
chair reviews two changes. Everyone willing to adopt?
20:05:25 [gpilz]
s/and an problem is detected/and a problem is detected/
20:05:49 [Bob]
also change MUST/MAY
20:06:27 [Bob]
and s/InvalidEPR/UnusableEPR
20:07:30 [marklittle]
chair no objections.
20:07:36 [marklittle]
resolution: adopted 6696 as per the bugzilla resolution and incorporating the 3 changes mentioned previously.
20:07:38 [asir]
20:07:41 [dug]
make the same change to ws-enum too
20:08:02 [marklittle]
topic: 6724
20:08:08 [marklittle]
20:08:55 [DaveS]
Note: If someone wants to open up a word smithing issue wrt 6696, they need to make sure to include Enumeration as well as Eventing.
20:10:57 [Geoff]
20:11:24 [Wu]
20:11:42 [marklittle]
DaveS checks that cases where part of description can be updated and part may not be. Transfer supports this, correct?
20:11:44 [marklittle]
dug yes
20:12:14 [Bob]
ack geoff
20:12:55 [asir]
20:13:02 [Katy]
20:13:22 [DaveS]
20:13:23 [marklittle]
Geoff as usual not keen on making changes to functionality unless good reasons. Can't see good reasons with this one. Why delete current interfaces? Also general concern about moving to generalized interfaces versus specific interfaces. Can be confusing about what's happening.
20:13:24 [Katy]
20:13:56 [marklittle]
Geoff Seems like pointless thing. Why not add it and have it in conjunction with existing interfaces?
20:13:57 [Bob]
ack wu
20:14:09 [dug]
20:14:14 [Katy]
20:15:29 [marklittle]
Wu concerned on proposal too. Renew/getstatus well defined in eventing with well defined semantics. Shouldn't replace them. Maybe augment them instead, but definitely keep existing interfaces.
20:15:41 [Bob]
ack dave
20:16:28 [Bob]
20:16:34 [li]
20:17:31 [Wu]
not clear what kind of complexity that this will bring to WS-E and how interoperable.
20:17:33 [marklittle]
DaveS if this was optional then it would be fine. Worried about supporting old and new approaches though. Is there anything different in the proposed semantics versus those that are already in the specification?
20:17:35 [Bob]
20:17:43 [marklittle]
dug not my intent to break the semantics.
20:18:37 [Bob]
ack dug
20:18:56 [Bob]
ack katy
20:18:59 [marklittle]
dug understands the arguments about generic versus specific. Thought removing old interfaces was better so that there were not multiple ways of doing the same thing. But thinks that the generic is good even if the old interfaces remain. Compromise?
20:19:41 [gpilz]
20:19:42 [marklittle]
Katy thinks it's an interesting proposal.
20:21:19 [marklittle]
chair asks dug if this presents challenges to distributed implementations, particularly when asked "where is the state?" Could implement eventing where state is placed in to clusters. This proposal would require that representation to be mapped from wherever it is accessed. Does there need to be any kind of consistency control (transactions, locking)?
20:21:26 [Bob]
ack bob
20:21:33 [marklittle]
dug that's an implementation detail.
20:22:33 [marklittle]
dug maybe this is a general transfer question?
20:23:47 [Bob]
ack li
20:25:07 [Wu]
20:25:36 [Zakim]
20:25:49 [dug]
20:26:01 [Bob]
ack gpi
20:26:16 [Zakim]
+ +2
20:27:28 [DaveS]
Dave dropped briefly
20:28:00 [dug]
LOL blame me???
20:28:19 [marklittle]
gpilz likes proposal but not the notion of replacing the existing interfaces.
20:29:00 [gpilz]
more accurately I don't like the idea of using WS-T Put to do things like Renew and Cancel
20:29:16 [marklittle]
chair summarizes that people like proposal if it augments the existing rather than replaces.
20:29:22 [gpilz]
but I think using WS-T Get to get a "more detailed version" of the subscription status is usefull
20:29:56 [Wu]
20:29:57 [marklittle]
chair could we remove point 1 in proposal? No objections.
20:30:00 [dug]
gil - the proposal doesn't talk about cancel. And people are not required to support Put.
20:30:09 [Geoff]
20:30:21 [marklittle]
chair ok let's remove point 1 on proposal. Anyone disagree that reading full XML of subscription is not a good idea?
20:30:22 [li]
subscriber knows properties of subscription except the expire which may change, so getting other properties is not necessary
20:30:29 [Bob]
ack dug
20:32:30 [Bob]
ack geo
20:32:30 [li]
if updating other properties is necessary, can we argment renew operation for that?
20:32:38 [Zakim]
- +0208234aacc
20:32:38 [DaveS]
20:32:39 [marklittle]
Geoff what's difference between this and having GetStatus being extensible so that certain event sources can return more information?
20:32:54 [marklittle]
dug asks for clarification.
20:33:04 [Zakim]
+ +0125669aaff
20:33:14 [marklittle]
Geoff GetStatus already has extensibility element in there. So why not just use that?
20:34:11 [marklittle]
dug an interoperable solution isn't possible that way for getting all properties of subscription unless we specify it in the specification. Could add an optional parameter to GetStatus but that feels like replicating transfer and duplicating functionality.
20:35:13 [asir]
20:35:14 [Bob]
ack dave
20:35:36 [Zakim]
- +0125669aaff
20:36:35 [Zakim]
20:36:40 [marklittle]
DaveS wants uniform management capability.
20:36:40 [li]
20:36:58 [marklittle]
chair any objection to defining a standard XML representation to subscription manager?
20:37:04 [Bob]
ack asir
20:37:04 [marklittle]
Geoff not ready to do that yet.
20:37:30 [marklittle]
resolution: point 1 to proposal removed by consensus.
20:37:46 [Bob]
ack li
20:38:33 [marklittle]
li defining representation for subscription manager means resolving another EPR related issue: when do subscribe get back subscription manger EPR but no definition of how to take an EPR and get resource from it?
20:39:03 [marklittle]
topic: 6850
20:39:06 [marklittle]
20:39:42 [marklittle]
remove it
20:39:43 [marklittle]
20:39:46 [gpilz]
20:39:49 [Wu]
20:39:52 [marklittle]
chair any discussion?
20:39:58 [Bob]
ack wu
20:40:17 [dug]
20:40:24 [gpilz]
20:40:32 [marklittle]
Wu wants to keep it. Eventing doesn't have a direct reference to SOAP. Eventing should have it. Benefit to the statement so that people can see it has value outside of SOAP.
20:40:33 [dug]
By using the XML, SOAP [SOAP 1.1], [SOAP 1.2], and WSDL [WSDL 1.1] extensibility models, the Web service specifications (WS-*) are designed to be composed with each other to provide a rich set of tools to provide security in the Web services environment.
20:40:41 [Bob]
ack dug
20:40:48 [marklittle]
dug eventing does talk about SOAP.
20:41:38 [Bob]
ack gpi
20:42:26 [marklittle]
gpilz thinks Wu's assertion is not correct. Well understood design patterns for pub/sub. WS-Eventing is about this pattern in SOAP. That is its reason for existence.
20:42:28 [marklittle]
20:42:32 [Wu]
20:43:48 [Bob]
ack wu
20:43:58 [gpilz]
20:44:04 [dug]
20:44:30 [marklittle]
Wu thinks semantics of ws-e can be applied to non-SOAP environment and that ws-e is more than pub/sub. Removing SOAP reference removes value as well to ws-e.
20:45:16 [marklittle]
-1 to Wu
20:45:30 [Bob]
ack gpi
20:45:35 [DaveS]
20:45:50 [marklittle]
gpilz if we push ws-* useful outside of SOAP then it's a long troubled road.
20:45:52 [Ashok]
20:45:59 [Wu]
WS-E semantics are defned depending on SOAP and we should not confine ourselves to only for SOAP.
20:46:23 [marklittle]
+1 to gil. We shouldn't compete with OMG, JCP etc.
20:46:38 [Wu]
s/defined depending/defined NOT depending/ on SOAP
20:46:46 [Bob]
ack dug
20:47:32 [marklittle]
dug removing sentence doesn't change anything, so Wu argument that it would change the meaning that we can't use ws-e outside of SOAP is not valid. Having it is inconsistent.
20:47:58 [marklittle]
Wu agrees.
20:48:11 [DaveS]
20:48:17 [Wu]
I am more friendly to it.
20:48:17 [marklittle]
chair any disagreements on proposal? none.
20:48:23 [Ashok]
20:48:27 [marklittle]
chair can we resolve according to proposal? Yes.
20:48:39 [marklittle]
resolution: issue is resolved as per proposal.
20:49:02 [gpilz]
what did I do?
20:49:26 [marklittle]
topic: 6594
20:49:29 [marklittle]
20:49:35 [Geoff]
20:49:57 [Bob]
ack geo
20:50:52 [marklittle]
Geoff has been discussing with dug around wording. Dug has suggestion by separating concept of changes and additional requirements to the spec. Can treat them separately and let the first part of this proposal to go through.
20:50:52 [dug]
20:52:53 [asir]
in cricket, it is called a hatrick
20:53:12 [marklittle]
6594 6672 6673
20:53:18 [Bob]
N.B. this resolves 6594, 6672, 6673
20:53:32 [marklittle]
Geoff take action item to open new issue on closing these issues.
20:54:46 [marklittle]
chair can we take proposal to resolve 6594, 6672 and 6673 with document attached to Any objections?
20:54:47 [marklittle]
20:54:57 [marklittle]
just ;-)
20:55:09 [marklittle]
chair no objections. resolved.
20:55:21 [marklittle]
resolution: resolved 6594, 6672 and 6673 with document attached to
20:55:41 [marklittle]
chair let's not push our luck and go have a few drinks of wine ;-)
20:55:52 [Zakim]
20:55:53 [Zakim]
20:55:54 [Zakim]
- +1.571.262.aadd
20:55:55 [Zakim]
20:55:55 [Zakim]
20:55:57 [Zakim]
20:55:58 [Zakim]
20:55:58 [Zakim]
20:56:00 [Zakim]
20:56:01 [Zakim]
20:56:03 [Zakim]
- +0208234aabb
20:56:03 [RRSAgent]
I have made the request to generate Yves
20:56:10 [Zakim]
20:56:12 [Zakim]
20:56:28 [Zakim]
- +2
20:56:29 [Zakim]
WS_WSRA()3:30PM has ended
20:56:30 [Zakim]
Attendees were Bob_Freund, [Microsoft], asir, Mark_Little, [IBM], Tom_Rutt, doug, Wu_Chou, +0125669aaaa, Dave, +0208234aabb, +0208234aacc, Gilbert, Ashok_Malhotra, Yves,
20:56:32 [Zakim]
... +1.571.262.aadd, JeffM, +2, +0125669aaff, Katy_Warr
20:57:02 [gpilz]
gpilz has left #ws-ra
20:57:49 [Yves]
trackbot, end telcon
20:57:49 [trackbot]
Zakim, list attendees
20:57:49 [Zakim]
sorry, trackbot, I don't know what conference this is
20:57:50 [trackbot]
RRSAgent, please draft minutes
20:57:50 [RRSAgent]
I have made the request to generate trackbot
20:57:51 [trackbot]
RRSAgent, bye
20:57:51 [RRSAgent]
I see no action items