IRC log of ws-ra on 2009-10-27

Timestamps are in UTC.

19:29:50 [RRSAgent]
RRSAgent has joined #ws-ra
19:29:50 [RRSAgent]
logging to http://www.w3.org/2009/10/27-ws-ra-irc
19:29:52 [trackbot]
RRSAgent, make logs public
19:29:52 [Zakim]
Zakim has joined #ws-ra
19:29:54 [trackbot]
Zakim, this will be WSRA
19:29:54 [Zakim]
ok, trackbot, I see WS_WSRA()3:30PM already started
19:29:55 [trackbot]
Meeting: Web Services Resource Access Working Group Teleconference
19:29:55 [trackbot]
Date: 27 October 2009
19:30:07 [Bob]
chair: Bob Freund
19:30:34 [Bob]
note that w3c list servers are jammed
19:30:40 [gpilz]
gpilz has joined #ws-ra
19:30:46 [Wi]
Wi has joined #ws-ra
19:30:50 [MartinC]
MartinC has joined #ws-ra
19:31:01 [Tom_Rutt]
Tom_Rutt has joined #ws-ra
19:31:10 [Zakim]
+[Microsoft]
19:31:11 [Zakim]
- +91.98.49.99.aaaa
19:31:22 [Katy]
Bob- I will be a few minutes late joining the call today
19:31:34 [Zakim]
+Wu_Chou
19:31:35 [Zakim]
+ +1.703.860.aabb
19:31:40 [Zakim]
+ +984999aacc
19:31:40 [Zakim]
+ +1.408.642.aadd
19:31:58 [gpilz]
zakim, 408.642.aadd is gpilz
19:31:58 [Zakim]
sorry, gpilz, I do not recognize a party named '408.642.aadd'
19:32:09 [Zakim]
+Tom_Rutt
19:32:09 [dug]
zakim, who is on?
19:32:09 [Zakim]
I don't understand your question, dug.
19:32:12 [gpilz]
zakim, add is gpilz
19:32:12 [Zakim]
sorry, gpilz, I do not recognize a party named 'add'
19:32:24 [asir]
asir has joined #ws-ra
19:32:27 [Ram]
Ram has joined #ws-ra
19:32:27 [Ashok]
Ashok has joined #ws-ra
19:32:27 [gpilz]
zakim, open the pod bay door
19:32:27 [Zakim]
I don't understand 'open the pod bay door', gpilz
19:32:33 [dug]
LOL
19:32:42 [dug]
zakim, make love
19:32:42 [Zakim]
I don't understand 'make love', dug
19:32:43 [Zakim]
+fmaciel
19:32:50 [gpilz]
zakim, "aadd" is gpilz
19:32:50 [Zakim]
sorry, gpilz, I do not recognize a party named '"aadd"'
19:33:01 [Wu]
Wu has joined #ws-ra
19:33:11 [gpilz]
zakim, +1.408.642.add is gpilz
19:33:11 [Zakim]
sorry, gpilz, I do not recognize a party named '+1.408.642.add'
19:33:13 [Zakim]
+ +03531498aaee
19:33:23 [dug]
zakim, 642 is gpilz
19:33:23 [Zakim]
sorry, dug, I do not recognize a party named '642'
19:33:37 [li]
zakim, aadd is gpilz
19:33:37 [Zakim]
+gpilz; got it
19:33:42 [Zakim]
+Ashok_Malhotra
19:33:45 [dug]
whose kid is talking? :-)
19:34:09 [dug]
Yves????
19:34:10 [MartinC]
zakim, aaee is MartinC
19:34:10 [Zakim]
+MartinC; got it
19:34:18 [Zakim]
+Yves
19:34:30 [dug]
yves - can you unblock me? 129.33.49.251
19:34:51 [Yves]
dug, I'll try
19:34:54 [dug]
thanks
19:35:43 [Yves]
you're banned from two mirrors, good job ;)
19:36:07 [dug]
LOL when i do something I go all out!
19:37:19 [gpilz]
scribe: gpilz
19:37:37 [gpilz]
topic: agenda
19:37:42 [gpilz]
bob: some probs getting it out
19:37:47 [gpilz]
... everyone get it?
19:37:57 [gpilz]
(no reply)
19:37:59 [Sreed]
Sreed has joined #ws-ra
19:38:06 [gpilz]
bob: i'll fix minutes later
19:38:19 [gpilz]
topic: minutes
19:38:26 [gpilz]
bob: minutes came out fairly recently
19:38:33 [gpilz]
... anybody need more time for 10/20?
19:38:35 [Yves]
dug, done (will be temporary, I fear)
19:38:36 [gpilz]
(no reply)
19:38:52 [Ram]
q+
19:38:55 [dug]
thanks - seems ok for now
19:38:57 [gpilz]
resolution: minutes from 10/20 accepted by UC
19:39:04 [gpilz]
topic: F2F logistics
19:41:12 [gpilz]
bob: Fredrick Hirsh contacted us about XPath-subset for fragment specification
19:41:38 [asir]
q+ to ask a question
19:41:53 [Ram]
q-
19:42:09 [gpilz]
... they (XML Security WG) would like to caucus on 11/5
19:42:13 [Bob]
ack asir
19:42:13 [Zakim]
asir, you wanted to ask a question
19:42:16 [Vikas]
Vikas has joined #ws-ra
19:42:25 [Zakim]
+JeffM
19:43:01 [gpilz]
topic: new issues
19:43:04 [Ram]
q+
19:43:07 [gpilz]
bob: 8 new issues
19:43:13 [Ram]
q-
19:43:33 [gpilz]
.. any objection to accepting all new issues and assigning ownership to the raiser?
19:43:36 [gpilz]
(no reply)
19:43:43 [gpilz]
resolution: new issues accepted
19:43:51 [gpilz]
topic: issues with proposals
19:44:24 [gpilz]
topic: 7586, 7588, 7828
19:44:25 [gpilz]
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0044.html
19:44:37 [jeffm]
jeffm has joined #ws-ra
19:44:43 [Ram]
q+
19:44:52 [Bob]
ack ram
19:44:56 [gpilz]
ram: I agree with this
19:45:04 [gpilz]
bob: any objection to accepting this proposal
19:45:22 [gpilz]
resolution: 7586, 7588, 7828 resolved as per above proposal
19:45:57 [gpilz]
topic: 7911
19:46:08 [gpilz]
q+
19:46:14 [Bob]
ack gpi
19:46:34 [gpilz]
yves: need some more time
19:46:47 [gpilz]
gil: proposing CWNA, why would you need more time?
19:47:09 [gpilz]
bob: any objections to CWNA?
19:47:43 [dug]
q+
19:47:48 [gpilz]
yves: (reviews email dialog)
19:48:02 [asoldano]
asoldano has joined #ws-ra
19:48:04 [gpilz]
... if we use MAY, that would be enough
19:48:28 [gpilz]
bob: are you proposing to say something like "they MAY"?
19:48:32 [gpilz]
yves: yes
19:48:46 [gpilz]
bob: any objection to it being a generic SOAP sender fault
19:49:03 [gpilz]
... any objections?
19:49:03 [Bob]
ack dug
19:49:08 [gpilz]
doug: I object
19:49:11 [Zakim]
+ +039331574aaff
19:49:18 [gpilz]
... as you know, I like consitency
19:49:29 [gpilz]
... I agree that a generic SOAP Sender fault is the appropriate thing
19:49:41 [gpilz]
... but why are we focusing on this particular error?
19:49:48 [gpilz]
... there are lots of things that could be wrong
19:49:51 [Ram]
q+
19:49:55 [gpilz]
... why call out this particular problem
19:50:01 [Tom_Rutt]
q+
19:50:02 [Ram]
q-
19:50:11 [gpilz]
... readers will wonder what is special about this condition
19:50:25 [gpilz]
... bad thing to imply that there is something special about this error condition
19:50:37 [gpilz]
... this is covered by a generic SOAP fault
19:50:45 [gpilz]
bob: I want to move things along here
19:50:51 [gpilz]
... limit to 2 times in the queue
19:50:56 [Bob]
ack tom
19:51:00 [Ram]
q+
19:51:01 [gpilz]
tom: I was going to say the same thing
19:51:05 [gpilz]
... SOAP covers this
19:51:08 [Bob]
ack yves
19:51:22 [gpilz]
yves: the SOAP spec doesn't cover this at all - verbs etc. not covered
19:51:38 [gpilz]
... we are defining in two places the way the receiver should process the message, so this is an issue
19:51:45 [asoldano]
I apologize for being late, forgot about the timezone change because of daylight saving
19:52:04 [Bob]
ack ram
19:52:04 [gpilz]
... you can claim there is a requirement on the SENDER, but there is no corresponding requirement on the RECEIVER
19:52:20 [gpilz]
ram: fundamental problem is the WG has introduced this new wrapper
19:52:28 [gpilz]
... doesn't change the semantics of the protocol
19:52:44 [gpilz]
... dummy wrapper is functionally insignificant
19:52:58 [gpilz]
... now we have to worry about a mismatch
19:53:36 [gpilz]
... I saw one of Doug's email exchanges; the semantics have to be consistent
19:53:43 [gpilz]
bob: anybody else?
19:53:52 [gpilz]
(no reply)
19:54:07 [gpilz]
resolution: 7911 tabled for further consideration
19:54:11 [Ram]
Ram has joined #ws-ra
19:54:19 [jeffm]
i have a problem with a MAY
19:54:23 [jeffm]
completely worthless
19:54:27 [dug]
me too
19:54:37 [Ram]
Proposal: “If the semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages does not match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages, the receiver MUST generate a ActionAndWrapperMismatch fault”
19:54:37 [gpilz]
bob: does anyone have a problem with "MAY generate a sender fault"
19:54:38 [asoldano]
Zakim, +039331574aaff is asoldano
19:54:38 [Zakim]
+asoldano; got it
19:54:39 [Yves]
ok so my proposal will have a MUST then
19:54:51 [dug]
LOL yves
19:54:52 [Ram]
q+
19:54:56 [Yves]
;)
19:54:56 [gpilz]
(misc people have problem with "MAY generate")
19:55:13 [Bob]
ack ram
19:55:20 [gpilz]
ram: let's not worry about MUST or MAY
19:55:30 [gpilz]
... just focus on the semantics
19:55:34 [gpilz]
q+
19:55:50 [gpilz]
... if we agree to the first part, we can work on the MAY, SHOULD, MUST
19:56:08 [Bob]
ack gp
19:56:23 [Ram]
q+
19:56:32 [gpilz]
gil: I don't agree with the semantics
19:56:34 [Tom_Rutt]
q+
19:56:53 [Katy]
Katy has joined #ws-ra
19:56:54 [gpilz]
... don't see why this case, out of all the possible error cases, should be singled out for special treatment
19:57:19 [Bob]
ack ram
19:57:23 [Bob]
ack tom
19:57:24 [dug]
LOL tom
19:57:33 [Zakim]
+ +0125660aagg
19:57:53 [gpilz]
I've put the backhoe through the cable (actually a roto-tiller, but the effect was the same)
19:58:47 [gpilz]
topic: 7015
19:59:02 [gpilz]
bob: issue has been around since Redwood Shores F2F
19:59:10 [gpilz]
... proposal is contained in the issue itself
19:59:24 [gpilz]
... is there a Microsoft rep willing to speak to this
19:59:32 [gpilz]
ram: won't repeat what is already there
19:59:48 [gpilz]
... 7911 is a resolution to this issue
20:00:00 [gpilz]
... unless we can resolve 7911 we can't resolve this issue
20:00:15 [gpilz]
... but there is another way to resolve this
20:00:20 [gpilz]
bob: you have a new proposal?
20:00:23 [gpilz]
ram: yes . . . .
20:00:54 [Ram]
Ram has joined #ws-ra
20:01:04 [Ram]
Proposal: “If the semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages does not match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages, the receiver MUST generate a Server fault”
20:01:35 [gpilz]
ram: I understand there are some reservations against the use of MUST
20:01:47 [gpilz]
... the semantics of the wrapper element and the action URI must be the same
20:01:59 [Ram]
yes
20:02:01 [gpilz]
bob: this looks like the proposal for 7911
20:02:08 [gpilz]
... omnibus proposal
20:02:13 [dug]
q+
20:02:32 [gpilz]
bob: any objections?
20:02:39 [gpilz]
gil: I object
20:02:48 [gpilz]
doug: I don't see what this has to do with 7015
20:03:04 [gpilz]
... I thought the problem was in having a separate wrapper per operation
20:03:15 [gpilz]
bob: if you read the last paragraph of the issue the connection is clear
20:03:19 [gpilz]
q+
20:03:29 [gpilz]
doug: I'm not sure I see it, can you point out the sentence
20:04:02 [gpilz]
"The decision here, to require that the name of the first child element match the action, makes ambiguous the role of the first child element in defining the verb used for routing messages. Implementers could incorrectly dispatch using the first child element as the verb, rather than support the WS-Addressing action as the verb. Replication of information always decreases interoperability, and this continued polarization has to stop if interoperability is to be
20:04:14 [gpilz]
bob: ram's proposal defines what should happen if there is a mismatch
20:04:28 [gpilz]
doug: the issue in front of here is that there may be a mismatch
20:04:35 [gpilz]
... this puts us back to 7911
20:04:51 [gpilz]
... the specification is quite clear on what [Action], [Body], should be
20:05:01 [gpilz]
... not clear what else we need to specify
20:05:09 [gpilz]
... all other SOAP specs do it this way
20:05:10 [asoldano]
+1
20:05:13 [Ram]
q+
20:05:16 [Bob]
ack dug
20:05:18 [gpilz]
... propose we CWNA
20:06:36 [Ram]
Proposal 2: "The semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages MUST match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages".
20:06:41 [gpilz]
gil: thinks CWNA
20:06:48 [Wu]
q+
20:06:51 [gpilz]
bob: any objection to CWNA?
20:06:55 [gpilz]
yves: I object
20:06:56 [Bob]
ack gpi
20:07:05 [gpilz]
ram: would like to agree to something and move on
20:07:14 [gpilz]
... see above proposal
20:08:10 [gpilz]
bob: any objection to the above?
20:08:20 [dug]
"The Get request message MUST be of the following form:"
20:08:22 [gpilz]
doug: I object; this is already in the spec
20:08:27 [gpilz]
... see above
20:08:33 [gpilz]
... why are we repeating this MUST?
20:08:51 [Yves]
this MUST is a sender requirement, not a receiver requirement
20:08:57 [jeffm]
hey: i have a modest proposal that maybe we could all agree to in the spirit of compromise - Close with no action
20:08:57 [gpilz]
ram: doesn't that seem to be a shorter way of saying what you said above?
20:09:12 [gpilz]
oops (bob said above)
20:09:17 [gpilz]
ram: no, I don't agree
20:09:27 [Tom_Rutt]
q+
20:09:28 [gpilz]
... doesn't hurt to add the statement we want
20:09:33 [Bob]
ack ram
20:09:36 [gpilz]
... helps people understand better
20:09:38 [jeffm]
q+
20:09:43 [gpilz]
bob: ram, not clear on what you said
20:10:07 [dug]
+1 yves - CWNA and move on :-)
20:10:10 [Katy]
q+
20:10:18 [gpilz]
ram: the group has different opinions about whether we need the extra statement
20:10:32 [Bob]
ack wu
20:10:42 [Yves]
dug, I just said move on
20:10:45 [gpilz]
... the statement helps those of use that don't understand the use of separate [Action]/[Body]
20:10:50 [gpilz]
wu: two issues are related
20:10:56 [gpilz]
... we tabled 7911
20:10:58 [dug]
MAY move on :-)
20:11:00 [gpilz]
... we should table this
20:11:16 [gpilz]
bob: there was no objection to discussing this issue when we discussed agenda
20:11:19 [gpilz]
... let's continue
20:12:16 [gpilz]
... is there anyone who would accept Ram's first proposal
20:12:19 [gpilz]
wu: which one?
20:12:42 [Ram]
q+
20:12:42 [gpilz]
bob: (reads first proposal - see above)
20:13:11 [gpilz]
... (reads second proposal - see above)
20:13:27 [gpilz]
... third proposal is CWNA
20:13:37 [Bob]
ack tom
20:13:39 [gpilz]
tom: I support CWNA
20:13:48 [gpilz]
... it's already covered in the existing spec
20:13:54 [asoldano]
q+
20:13:56 [gpilz]
... it's unnecessary to add this extra statement
20:13:57 [MartinC]
MartinC has joined #ws-ra
20:13:59 [Bob]
ack jeff
20:14:04 [gpilz]
... the requirment is already there
20:14:14 [gpilz]
jeffm: ram, what changes with your proposal?
20:14:25 [Yves]
hum, SOAP explicitely say that receivers may check the schema validity but it is not required (while the spec says that the sender must produce something based on the schema)
20:14:34 [gpilz]
... is something that was legal is now illegal, or this there something that was illegal that is now legal
20:14:42 [gpilz]
... if nothing changes, this is a no-op
20:14:43 [gpilz]
ram:
20:15:06 [gpilz]
ram: first of all, the proposal really helps that there is a consitency of understanding
20:15:18 [gpilz]
... if it's not there there is possibility,
20:15:34 [gpilz]
... some implementation rely on Action others on Body/child
20:15:44 [gpilz]
... it's not just me that has this problem, yves agreess
20:15:50 [gpilz]
jeffm: that's not my question
20:15:59 [gpilz]
... what specific messages would become illegal?
20:16:11 [gpilz]
ram: my proposal just re-states what the spec is trying to say
20:16:20 [gpilz]
jeffm: that's not a compelling argument
20:16:38 [gpilz]
ram: let's just put this to rest and add this harmless text and move on
20:16:48 [gpilz]
bob: doug quoted the text that now says this
20:17:00 [gpilz]
... is your proposal an editorial moditication on this text?
20:17:06 [gpilz]
ram: yes, it doesn't change anything
20:17:11 [dug]
"The Get request message MUST be of the following form:"
20:17:25 [Ram]
Proposal 2: The semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages MUST match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages.
20:17:54 [gpilz]
doug: I don't see how there could possibly be any confusion around this
20:18:03 [gpilz]
q+
20:18:14 [Ram]
Proposal 2 makes the intent clearer.
20:18:26 [gpilz]
bob: is there any difference between these two?
20:18:30 [asir]
Ram did not propose a replacement
20:18:30 [gpilz]
doug: yes!
20:18:50 [Bob]
ack katy
20:18:51 [gpilz]
... this decreases interop because it only talks about [Action] and [Body]
20:19:05 [gpilz]
katy: I think this is crazy and gives spec writing a bad name
20:19:21 [Yves]
there is a difference between putting requirement on the message form (ie: a sender requirement), and a receiver requirement of ensuring that the message is correct or not
20:19:22 [gpilz]
... I'm very uncomfortable with special casing WS-Transfer
20:19:23 [Bob]
ack ram
20:19:29 [gpilz]
ram: I think we can all agree on one thing
20:19:39 [gpilz]
... we all want to read the spec and come out with the same interpretation
20:19:53 [gpilz]
... it helps us if we add that one line and makes things clearer for us
20:20:05 [Wu]
q+
20:20:07 [gpilz]
... let's move forward and just add this one, harmless sentence
20:20:22 [Bob]
ack aso
20:20:28 [Yves]
in SOAP, it was explicitely said that schema validity checking was optional, because of performance, and because there are other ways to verify inputs
20:20:29 [dug]
What other interpretation could there be?
20:20:31 [Bob]
ack gp
20:20:31 [gpilz]
alession: we don't need this sentence
20:21:02 [Bob]
ack wu
20:21:10 [gpilz]
gil: what's in the spec now is easier to understand than Ram's proposal
20:21:19 [gpilz]
wu: we have similar questions to Ram
20:21:29 [gpilz]
... but ask the question "what do we do if they are not the same"
20:21:34 [gpilz]
... wording can be refined
20:21:44 [gpilz]
... suggest Ram work with people to refine the text
20:21:57 [dug]
all specs
20:21:58 [dug]
?
20:22:23 [gpilz]
bob: recognize yves to voice IRC comment
20:22:44 [gpilz]
yves: would be willing to work with Doug and Gil to resolve this w/out taking up WG time
20:22:54 [gpilz]
... requirement is currently on SENDER
20:23:19 [dug]
q+
20:23:20 [gpilz]
... but leaves open the issue of what a RECEIVER is required to do
20:23:48 [gpilz]
doug: I'm a little confused
20:24:08 [gpilz]
... if there is this much confusion about [Action] and [Body], does this apply to all specs
20:24:16 [gpilz]
ram: I can only speak for myself and my product team
20:24:24 [gpilz]
... for us the problem is in WS-Transfer
20:25:02 [gpilz]
doug: it seems to me that this has to cut across all the other specs since they all do things the same way (individual and separate [Action] and [Body]/child)
20:25:07 [gpilz]
... I'm confused by the confusion
20:25:15 [gpilz]
... what possible other interpretation could there be?
20:25:49 [gpilz]
ram: this goes back to what this WG has done over the last several months
20:26:10 [gpilz]
... if you look at this from the perspective of someone who has previously implemented the Member Submission of WS-T
20:26:21 [gpilz]
... they have to wonder why these wrappers have added
20:26:29 [gpilz]
... it doesn't improve the protocol in any way
20:26:49 [gpilz]
... we owe an explantion to these people about why we introduced this wrapper and what it's semantics are
20:27:09 [gpilz]
... because we introduced ... raise a fundamental question
20:27:16 [gpilz]
... why is this wrapper there in the first place?
20:27:27 [gpilz]
doug: you didn't answer my question
20:27:32 [gpilz]
... you said there is confusion
20:27:47 [gpilz]
... you said that there could be two outcomes?
20:27:51 [gpilz]
... what is the second outcome?
20:28:06 [gpilz]
ram: my point is from the context of people who aren't used to this wrapper
20:28:12 [gpilz]
doug: you are claiming there is confusion
20:28:22 [gpilz]
... therefore there must be two possible outcomes
20:28:32 [gpilz]
... please tell me what this second outcome could be?
20:28:40 [gpilz]
ram: just need to make things clear
20:28:46 [gpilz]
bob: everyone has had their turn
20:28:48 [Ram]
q+
20:28:53 [dug]
q-
20:29:10 [gpilz]
... 3 proposals on the table
20:29:18 [gpilz]
... let's see if we can inch closer
20:29:33 [Ram]
I am willing to go with just proposal 2.
20:29:35 [gpilz]
... my sense of the group is that proposal 1 had a substantially strong rejection rate
20:29:46 [gpilz]
... proposal 2 - people didn't understand what it changed
20:29:56 [gpilz]
... proposal 3 (CWNA) - changes nothing
20:30:03 [gpilz]
... proposal 1 seems like a non-starter
20:30:10 [Tom_Rutt]
q+
20:30:17 [gpilz]
... between 2 & 3, is there something we can put together?
20:30:31 [Ram]
q-
20:30:36 [Katy]
q+
20:30:43 [gpilz]
tom: I think it's a waste of ink and space
20:30:46 [asir]
q+
20:30:52 [gpilz]
... CWNA keeps things the same on the wire
20:30:55 [Bob]
ack tom
20:30:55 [gpilz]
... why bother?
20:31:01 [Bob]
ack katy
20:31:10 [Zakim]
-JeffM
20:31:10 [gpilz]
katy: part of the job of the WG is to make sure the specs align with each other
20:31:20 [gpilz]
... if we add this text, we have to add it to all 5 specs
20:31:24 [Ram]
q+
20:31:26 [gpilz]
... think CWNA
20:31:34 [asir]
q-
20:31:42 [gpilz]
bob: katy, is there a variation of 2 that would be more attractive to you?
20:31:43 [dug]
less is more :-0
20:31:46 [gpilz]
katy: not really
20:31:52 [gpilz]
... this text is just not needed
20:31:58 [gpilz]
... hasn't been needed in the past
20:32:13 [gpilz]
ram: if the concern is that this text appear in all specs
20:32:21 [gpilz]
... that's not my intent, WS-T only
20:32:26 [gpilz]
bob: why just WS-T?
20:32:36 [gpilz]
ram: because we added wrappers to WS-T
20:32:46 [dug]
because transfer readers can't read specs :-)
20:32:59 [gpilz]
bob: why isn't this a problem in the other specs?
20:33:04 [gpilz]
... it wasn't in MEX at one time
20:33:13 [gpilz]
ram: problem is that we've added wrappers
20:33:26 [Katy]
q+
20:33:31 [gpilz]
q+
20:33:43 [asir]
Transfer is based on the REST model where verbs are not part of messages
20:33:43 [gpilz]
... WS-T aligns with HTTP
20:33:46 [Bob]
ack ram
20:33:48 [gpilz]
... it doesn't need wrappers
20:33:56 [Bob]
ack katy
20:34:08 [gpilz]
katy: we implemented the previous version of MEX without wrappers
20:34:11 [Bob]
ack gpi
20:34:53 [gpilz]
gil: ram is re-arguing a closed issue - wrappers have been added to WS-T
20:35:30 [gpilz]
bob: seems to come down to proposal 2 and proposal 3
20:35:35 [MartinC]
MartinC has joined #ws-ra
20:35:37 [gpilz]
... jeff asked, what does this change?
20:35:52 [Zakim]
- +984999aacc
20:35:55 [gpilz]
... is there any modification to proposal 2 that would make people support it more?
20:36:01 [gpilz]
ram: that remains to be seen
20:36:10 [gpilz]
bob: this issue has been marinating a long time
20:36:13 [Tom_Rutt]
q+
20:36:16 [dug]
q+
20:36:21 [dug]
q-
20:36:25 [gpilz]
... trying to figure out if there is a constructive resolution that people can agree on
20:36:32 [dug]
I could go for a nice steak
20:36:41 [gpilz]
... since we have established that proposal 2 doesn't change wire behavior
20:36:46 [gpilz]
... we need to decide
20:37:04 [Wu]
q+
20:37:07 [Tom_Rutt]
q-
20:37:07 [gpilz]
... we are down to a vote
20:37:21 [Bob]
ack wu
20:37:28 [gpilz]
wu: proposals are close
20:37:35 [gpilz]
... we have a F2F meeting coming up
20:37:35 [Tom_Rutt]
q+
20:37:43 [gpilz]
... we have a chance to reach consensus
20:38:01 [gpilz]
bob: this is on the agenda for today
20:38:07 [gpilz]
... folks agreed to the agenda
20:38:16 [gpilz]
tom: nothing is going to change on the wire
20:38:18 [Bob]
ack tom
20:38:21 [gpilz]
... it is a tautology
20:38:34 [dug]
good word "tautology"
20:38:39 [gpilz]
... I don't want to set a precendent for adding statements that change nothing
20:39:00 [gpilz]
bob: (reviews our options)
20:39:16 [gpilz]
... unless there is a suggestion that modifies proposal 2 in some way
20:39:25 [gpilz]
... anyone need more time
20:39:30 [gpilz]
wu: we need more time
20:39:38 [gpilz]
... we might reach a better solution at the F2F
20:39:51 [gpilz]
bob: we've been through 3 F2F's with this issue on our books
20:40:00 [gpilz]
... it's the longest deferred issue
20:40:25 [dug]
proposal 2 also says less than what's there
20:40:28 [dug]
today.
20:40:34 [gpilz]
asir: yves said he wants to talk to gil and doug
20:40:39 [gpilz]
bob: wasn't that 7911?
20:40:46 [gpilz]
doug: that was my understanding
20:40:56 [gpilz]
yves: yes, that was 7911
20:41:08 [gpilz]
bob: we'll lay that over since it isn't months old (as 7015 is)
20:41:18 [gpilz]
... what else do we need to do for 7015?
20:41:22 [gpilz]
... anything not explored
20:41:41 [gpilz]
wu: I think the discussion Yves would have on 7911 will provide new angles on this issue
20:41:48 [gpilz]
... need to explore new angles
20:43:04 [gpilz]
bob: what else can we discover
20:43:21 [gpilz]
wu: i think what comes out of the discussion of 7911 will bear on this issue
20:43:25 [dug]
can we close 7015 w/no action with the assumption that 7911 will cover it?
20:43:29 [gpilz]
bob: these issues seem to have converged
20:43:53 [gpilz]
bob: is there anyone here who would like to deal with 7911 as the replacement issue for 7015 if they should be merged?
20:44:01 [gpilz]
doug: I'm confused, they are separate issues
20:44:22 [gpilz]
... if ram thinks covering Yves issue will resolve 7015, let's close 7015 and just work on 7911
20:44:26 [gpilz]
asir: not true
20:44:35 [gpilz]
... closing 7911 will help resolve 7015
20:45:10 [gpilz]
bob: 7911 and 7015 are separate issues
20:45:38 [asir]
listening to all the arguments it is hard to understand what is the pushback on proposal 2
20:45:52 [gpilz]
... does the current spec talk about the matching?
20:46:04 [gpilz]
doug: the current spec says what each message must contain
20:46:19 [gpilz]
bob: you quoted the text that says "messages must be of this form . . "
20:46:27 [gpilz]
(scribe is lost)
20:46:37 [asir]
there are implementations out there that do not enforce the outline but dispatch on wrapper names
20:47:24 [gpilz]
bob & doug: (deep dive into semantics)
20:48:06 [asir]
it doesn't
20:48:21 [gpilz]
bob: the snippet you provided with says "the messages must follow this form . . ."
20:48:31 [asir]
need to connect them in folks understanding
20:48:36 [gpilz]
... but it doesn't describe the relationship between [Action] and [Body]
20:48:42 [gpilz]
doug: it doesn't need to
20:48:56 [gpilz]
... it's not about the relationship between the two
20:49:04 [gpilz]
... messages must conform to the spec
20:49:28 [gpilz]
... and the spec says "[Action] must be blah, [Body] must be blah"
20:49:43 [gpilz]
bob: can anyone convince me that waiting until the F2F will help this?
20:49:52 [gpilz]
wu: ram can read the spec again more carefully
20:50:05 [gpilz]
bob: are you saying ram will agree to CWNA?
20:50:07 [gpilz]
wu: no
20:50:14 [gpilz]
... ram might find a new angle
20:50:34 [gpilz]
bob: ram, do you have a new angle that you might be able to find
20:50:41 [gpilz]
ram: I have thought about this problem long and hard
20:50:48 [gpilz]
... what I have right now is the best I have
20:51:00 [gpilz]
... there is always a possibility that i will think of something new
20:51:07 [gpilz]
... but right now, this is the best i've got
20:51:51 [gpilz]
bob: we're all trying to do what is right
20:51:54 [dug]
under the table?
20:52:05 [gpilz]
... as me, bob (not the chair), I don't see what the point of proposal 2 is
20:52:08 [Ram]
q+
20:52:15 [gpilz]
... it says too much and too little
20:52:32 [Bob]
ack ram
20:52:37 [gpilz]
ram: i'm willing to work on it some more and try and come up with another proposal
20:52:41 [gpilz]
... i'm open to the possibility
20:52:58 [gpilz]
bob: i have to ask "is this your final answer" at some point
20:53:03 [gpilz]
... i'm tempted to do that now
20:53:17 [gpilz]
... unless there is a willingness to move, in some specific way, to a consensus
20:53:31 [gpilz]
... where is the willingness to move in a specific direction that will get us to consensus?
20:53:48 [gpilz]
ram: you are asking me if i am willing to move in a direction to achieve consensus?
20:53:54 [gpilz]
bob: yes, and what is it?
20:54:01 [gpilz]
... (this specific direction)
20:54:15 [gpilz]
ram: i have moved a long way from where i was weeks ago
20:54:26 [gpilz]
... i'm willing to move further
20:54:34 [gpilz]
... so we can all be happy
20:54:44 [gpilz]
bob: how close to CWNA are you willing to go?
20:54:51 [gpilz]
ram: CWNA is unacceptable
20:55:04 [gpilz]
bob: that's not the question, how close to CWNA are you willing to go?
20:55:11 [gpilz]
ram: CWNA is unacceptable
20:55:31 [gpilz]
bob: right now your proposal is not as broad as the current specification
20:55:38 [gpilz]
asir: can you elaborate on that?
20:55:45 [Tom_Rutt]
q+
20:55:51 [gpilz]
bob: current specs says "messages must be of this form . . ."
20:55:59 [gpilz]
... proposal 2 only addresses a subset
20:56:07 [gpilz]
asir: it's not a replacement, it's an addition
20:56:21 [gpilz]
bob: if proposal 2 were additive, would you be fine with that
20:56:38 [gpilz]
... do we have a deal?
20:56:40 [gpilz]
tom: no
20:56:44 [gpilz]
... we don't need anything
20:57:06 [gpilz]
bob: do we have two imovable objects?
20:57:14 [gpilz]
asir: i don't understand tom
20:57:37 [gpilz]
bob: tom said "no", as a person that writes profiles etc., proposal 2 wouldn't be anything he would want
20:57:48 [gpilz]
asir: this sentence doesn't add anything new
20:57:58 [gpilz]
bob: if it doesn't add anything new, why do we need it?
20:58:08 [gpilz]
asir: ram said he needs it to clarify things
20:58:10 [gpilz]
q+
20:58:21 [Tom_Rutt]
s/anything he would want/relevant to the actual test assertions that would be written/
20:58:21 [gpilz]
bob: everybody is saying that it adds nothing
20:58:29 [asoldano]
ok
20:58:34 [gpilz]
bob: permission to extend for 10 minutes
20:58:38 [fmaciel]
need to drop
20:58:42 [gpilz]
asir: i have another meeting to go to
20:58:50 [gpilz]
bob: let's vote right now
20:59:20 [gpilz]
asir: we've come up with another proposal (in our discussion)
20:59:27 [gpilz]
... adding proposal 2 to the existing text
20:59:38 [Bob]
The semantics (as defined by this specification) of the first child element of the SOAP Body [Body] of messages MUST match the semantics (as defined by this specification) of the message as uniquely identified by the WS-Addressing [Action] message addressing property contained in the SOAP Header of those messages and must be of this form:
20:59:42 [gpilz]
... some members have already left the meeting so I am not sure if we can vote
20:59:52 [gpilz]
bob: we don't have quorums in W3C
21:00:44 [gpilz]
redhat: CWNA
21:00:52 [gpilz]
oracle: CWNA
21:01:01 [gpilz]
microsoft: proposal 2
21:01:04 [gpilz]
ibm: CWNA
21:01:09 [gpilz]
fujitsu: CWNA
21:01:15 [gpilz]
hitachi: CWNA
21:01:26 [gpilz]
software AG: abstain
21:01:28 [Vikas1]
Vikas1 has joined #ws-ra
21:01:37 [gpilz]
avaya: proposal 2
21:02:18 [gpilz]
yves: proposal 2
21:02:52 [gpilz]
bob: vote is 3 to 5 (proposal 2 to CWNA)
21:02:59 [dug]
g'nite
21:03:05 [gpilz]
resolution: 7015 is CWNA by vote
21:03:06 [Zakim]
-Tom_Rutt
21:03:07 [MartinC]
MartinC has left #ws-ra
21:03:10 [Zakim]
-gpilz
21:03:10 [fmaciel]
fmaciel has left #ws-ra
21:03:11 [Zakim]
-Wu_Chou
21:03:11 [Zakim]
-Yves
21:03:12 [Zakim]
-Bob_Freund
21:03:12 [Zakim]
-MartinC
21:03:14 [Zakim]
- +1.703.860.aabb
21:03:14 [Zakim]
-asoldano
21:03:15 [Zakim]
-[IBM]
21:03:17 [Zakim]
-fmaciel
21:03:18 [Zakim]
-[Microsoft]
21:03:46 [Zakim]
- +0125660aagg
21:04:05 [Zakim]
-Ashok_Malhotra
21:04:06 [Zakim]
WS_WSRA()3:30PM has ended
21:04:07 [Zakim]
Attendees were [IBM], +91.98.49.99.aaaa, Bob_Freund, [Microsoft], Wu_Chou, +1.703.860.aabb, +984999aacc, +1.408.642.aadd, Tom_Rutt, fmaciel, +03531498aaee, gpilz, Ashok_Malhotra,
21:04:10 [Zakim]
... MartinC, Yves, JeffM, asoldano, +0125660aagg
21:04:17 [Bob]
rrsagent, generate minutes
21:04:17 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/10/27-ws-ra-minutes.html Bob
21:22:35 [gpilz]
gpilz has left #ws-ra
21:39:55 [dug]
dug has left #ws-ra
22:47:15 [asir]
asir has joined #ws-ra
23:33:30 [Zakim]
Zakim has left #ws-ra