Web Services Resource Access Working Group Teleconference -- 27 Oct 2009

<trackbot> Date: 27 October 2009

<Bob> note that w3c list servers are jammed

<Katy> Bob- I will be a few minutes late joining the call today

<dug> LOL

<dug> whose kid is talking? :-)

<dug> Yves????

<dug> yves - can you unblock me? 129.33.49.251

<Yves> dug, I'll try

<dug> thanks

<Yves> you're banned from two mirrors, good job ;)

<dug> LOL when i do something I go all out!

<scribe> scribe: gpilz

agenda

bob: some probs getting it out
... everyone get it?

(no reply)

bob: i'll fix minutes later

minutes

bob: minutes came out fairly recently
... anybody need more time for 10/20?

<Yves> dug, done (will be temporary, I fear)

(no reply)

<dug> thanks - seems ok for now

resolution: minutes from 10/20 accepted by UC

F2F logistics

bob: Fredrick Hirsh contacted us about XPath-subset for fragment specification
... they (XML Security WG) would like to caucus on 11/5

<Zakim> asir, you wanted to ask a question

new issues

bob: 8 new issues
... any objection to accepting all new issues and assigning ownership to the raiser?

(no reply)

resolution: new issues accepted

issues with proposals

7586, 7588, 7828

http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0044.html

ram: I agree with this

bob: any objection to accepting this proposal

resolution: 7586, 7588, 7828 resolved as per above proposal

7911

yves: need some more time

gil: proposing CWNA, why would you need more time?

bob: any objections to CWNA?

yves: (reviews email dialog)
... if we use MAY, that would be enough

bob: are you proposing to say something like "they MAY"?

yves: yes

bob: any objection to it being a generic SOAP sender fault
... any objections?

doug: I object
... as you know, I like consitency
... I agree that a generic SOAP Sender fault is the appropriate thing
... but why are we focusing on this particular error?
... there are lots of things that could be wrong
... why call out this particular problem
... readers will wonder what is special about this condition
... bad thing to imply that there is something special about this error condition
... this is covered by a generic SOAP fault

bob: I want to move things along here
... limit to 2 times in the queue

tom: I was going to say the same thing
... SOAP covers this

yves: the SOAP spec doesn't cover this at all - verbs etc. not covered
... we are defining in two places the way the receiver should process the message, so this is an issue

<asoldano> I apologize for being late, forgot about the timezone change because of daylight saving

yves: you can claim there is a requirement on the SENDER, but there is no corresponding requirement on the RECEIVER

ram: fundamental problem is the WG has introduced this new wrapper
... doesn't change the semantics of the protocol
... dummy wrapper is functionally insignificant
... now we have to worry about a mismatch
... I saw one of Doug's email exchanges; the semantics have to be consistent

bob: anybody else?

(no reply)

resolution: 7911 tabled for further consideration

<jeffm> i have a problem with a MAY

<jeffm> completely worthless

<dug> me too

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

bob: does anyone have a problem with "MAY generate a sender fault"

<Yves> ok so my proposal will have a MUST then

<dug> LOL yves

<Yves> ;)

(misc people have problem with "MAY generate")

ram: let's not worry about MUST or MAY
... just focus on the semantics
... if we agree to the first part, we can work on the MAY, SHOULD, MUST

gil: I don't agree with the semantics
... don't see why this case, out of all the possible error cases, should be singled out for special treatment

<dug> LOL tom

I've put the backhoe through the cable (actually a roto-tiller, but the effect was the same)

7015

bob: issue has been around since Redwood Shores F2F
... proposal is contained in the issue itself
... is there a Microsoft rep willing to speak to this

ram: won't repeat what is already there
... 7911 is a resolution to this issue
... unless we can resolve 7911 we can't resolve this issue
... but there is another way to resolve this

bob: you have a new proposal?

ram: yes . . . .

ram: I understand there are some reservations against the use of MUST
... the semantics of the wrapper element and the action URI must be the same

<Ram> yes

bob: this looks like the proposal for 7911
... omnibus proposal
... any objections?

gil: I object

doug: I don't see what this has to do with 7015
... I thought the problem was in having a separate wrapper per operation

bob: if you read the last paragraph of the issue the connection is clear

doug: I'm not sure I see it, can you point out the sentence

"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

bob: ram's proposal defines what should happen if there is a mismatch

doug: the issue in front of here is that there may be a mismatch
... this puts us back to 7911
... the specification is quite clear on what [Action], [Body], should be
... not clear what else we need to specify
... all other SOAP specs do it this way

<asoldano> +1

doug: propose we CWNA

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

gil: thinks CWNA

bob: any objection to CWNA?

yves: I object

ram: would like to agree to something and move on
... see above proposal

bob: any objection to the above?

<dug> "The Get request message MUST be of the following form:"

doug: I object; this is already in the spec
... see above
... why are we repeating this MUST?

<Yves> this MUST is a sender requirement, not a receiver requirement

<jeffm> hey: i have a modest proposal that maybe we could all agree to in the spirit of compromise - Close with no action

ram: doesn't that seem to be a shorter way of saying what you said above?

oops (bob said above)

ram: no, I don't agree
... doesn't hurt to add the statement we want
... helps people understand better

bob: ram, not clear on what you said

<dug> +1 yves - CWNA and move on :-)

ram: the group has different opinions about whether we need the extra statement

<Yves> dug, I just said move on

ram: the statement helps those of use that don't understand the use of separate [Action]/[Body]

wu: two issues are related
... we tabled 7911

<dug> MAY move on :-)

wu: we should table this

bob: there was no objection to discussing this issue when we discussed agenda
... let's continue
... is there anyone who would accept Ram's first proposal

wu: which one?

bob: (reads first proposal - see above)
... (reads second proposal - see above)
... third proposal is CWNA

tom: I support CWNA
... it's already covered in the existing spec
... it's unnecessary to add this extra statement
... the requirment is already there

jeffm: ram, what changes with your proposal?

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

jeffm: is something that was legal is now illegal, or this there something that was illegal that is now legal
... if nothing changes, this is a no-op

ram: ... first of all, the proposal really helps that there is a consitency of understanding
... if it's not there there is possibility,
... some implementation rely on Action others on Body/child
... it's not just me that has this problem, yves agreess

jeffm: that's not my question
... what specific messages would become illegal?

ram: my proposal just re-states what the spec is trying to say

jeffm: that's not a compelling argument

ram: let's just put this to rest and add this harmless text and move on

bob: doug quoted the text that now says this
... is your proposal an editorial moditication on this text?

ram: yes, it doesn't change anything

<dug> "The Get request message MUST be of the following form:"

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

doug: I don't see how there could possibly be any confusion around this

<Ram> Proposal 2 makes the intent clearer.

bob: is there any difference between these two?

<asir> Ram did not propose a replacement

doug: yes!
... this decreases interop because it only talks about [Action] and [Body]

katy: I think this is crazy and gives spec writing a bad name

<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

katy: I'm very uncomfortable with special casing WS-Transfer

ram: I think we can all agree on one thing
... we all want to read the spec and come out with the same interpretation
... it helps us if we add that one line and makes things clearer for us
... let's move forward and just add this one, harmless sentence

<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

<dug> What other interpretation could there be?

alession: we don't need this sentence

gil: what's in the spec now is easier to understand than Ram's proposal

wu: we have similar questions to Ram
... but ask the question "what do we do if they are not the same"
... wording can be refined
... suggest Ram work with people to refine the text

<dug> all specs

<dug> ?

bob: recognize yves to voice IRC comment

yves: would be willing to work with Doug and Gil to resolve this w/out taking up WG time
... requirement is currently on SENDER
... but leaves open the issue of what a RECEIVER is required to do

doug: I'm a little confused
... if there is this much confusion about [Action] and [Body], does this apply to all specs

ram: I can only speak for myself and my product team
... for us the problem is in WS-Transfer

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)
... I'm confused by the confusion
... what possible other interpretation could there be?

ram: this goes back to what this WG has done over the last several months
... if you look at this from the perspective of someone who has previously implemented the Member Submission of WS-T
... they have to wonder why these wrappers have added
... it doesn't improve the protocol in any way
... we owe an explantion to these people about why we introduced this wrapper and what it's semantics are
... because we introduced ... raise a fundamental question
... why is this wrapper there in the first place?

doug: you didn't answer my question
... you said there is confusion
... you said that there could be two outcomes?
... what is the second outcome?

ram: my point is from the context of people who aren't used to this wrapper

doug: you are claiming there is confusion
... therefore there must be two possible outcomes
... please tell me what this second outcome could be?

ram: just need to make things clear

bob: everyone has had their turn
... 3 proposals on the table
... let's see if we can inch closer

<Ram> I am willing to go with just proposal 2.

bob: my sense of the group is that proposal 1 had a substantially strong rejection rate
... proposal 2 - people didn't understand what it changed
... proposal 3 (CWNA) - changes nothing
... proposal 1 seems like a non-starter
... between 2 & 3, is there something we can put together?

tom: I think it's a waste of ink and space
... CWNA keeps things the same on the wire
... why bother?

katy: part of the job of the WG is to make sure the specs align with each other
... if we add this text, we have to add it to all 5 specs
... think CWNA

bob: katy, is there a variation of 2 that would be more attractive to you?

<dug> less is more :-0

katy: not really
... this text is just not needed
... hasn't been needed in the past

ram: if the concern is that this text appear in all specs
... that's not my intent, WS-T only

bob: why just WS-T?

ram: because we added wrappers to WS-T

<dug> because transfer readers can't read specs :-)

bob: why isn't this a problem in the other specs?
... it wasn't in MEX at one time

ram: problem is that we've added wrappers

<asir> Transfer is based on the REST model where verbs are not part of messages

ram: WS-T aligns with HTTP
... it doesn't need wrappers

katy: we implemented the previous version of MEX without wrappers

gil: ram is re-arguing a closed issue - wrappers have been added to WS-T

bob: seems to come down to proposal 2 and proposal 3
... jeff asked, what does this change?
... is there any modification to proposal 2 that would make people support it more?

ram: that remains to be seen

bob: this issue has been marinating a long time
... trying to figure out if there is a constructive resolution that people can agree on

<dug> I could go for a nice steak

bob: since we have established that proposal 2 doesn't change wire behavior
... we need to decide
... we are down to a vote

wu: proposals are close
... we have a F2F meeting coming up
... we have a chance to reach consensus

bob: this is on the agenda for today
... folks agreed to the agenda

tom: nothing is going to change on the wire
... it is a tautology

<dug> good word "tautology"

tom: I don't want to set a precendent for adding statements that change nothing

bob: (reviews our options)
... unless there is a suggestion that modifies proposal 2 in some way
... anyone need more time

wu: we need more time
... we might reach a better solution at the F2F

bob: we've been through 3 F2F's with this issue on our books
... it's the longest deferred issue

<dug> proposal 2 also says less than what's there

<dug> today.

asir: yves said he wants to talk to gil and doug

bob: wasn't that 7911?

doug: that was my understanding

yves: yes, that was 7911

bob: we'll lay that over since it isn't months old (as 7015 is)
... what else do we need to do for 7015?
... anything not explored

wu: I think the discussion Yves would have on 7911 will provide new angles on this issue
... need to explore new angles

bob: what else can we discover

wu: i think what comes out of the discussion of 7911 will bear on this issue

<dug> can we close 7015 w/no action with the assumption that 7911 will cover it?

bob: these issues seem to have converged
... is there anyone here who would like to deal with 7911 as the replacement issue for 7015 if they should be merged?

doug: I'm confused, they are separate issues
... if ram thinks covering Yves issue will resolve 7015, let's close 7015 and just work on 7911

asir: not true
... closing 7911 will help resolve 7015

bob: 7911 and 7015 are separate issues

<asir> listening to all the arguments it is hard to understand what is the pushback on proposal 2

bob: does the current spec talk about the matching?

doug: the current spec says what each message must contain

bob: you quoted the text that says "messages must be of this form . . "

(scribe is lost)

<asir> there are implementations out there that do not enforce the outline but dispatch on wrapper names

bob & doug: (deep dive into semantics)

<asir> it doesn't

bob: the snippet you provided with says "the messages must follow this form . . ."

<asir> need to connect them in folks understanding

bob: but it doesn't describe the relationship between [Action] and [Body]

doug: it doesn't need to
... it's not about the relationship between the two
... messages must conform to the spec
... and the spec says "[Action] must be blah, [Body] must be blah"

bob: can anyone convince me that waiting until the F2F will help this?

wu: ram can read the spec again more carefully

bob: are you saying ram will agree to CWNA?

wu: no
... ram might find a new angle

bob: ram, do you have a new angle that you might be able to find

ram: I have thought about this problem long and hard
... what I have right now is the best I have
... there is always a possibility that i will think of something new
... but right now, this is the best i've got

bob: we're all trying to do what is right

<dug> under the table?

bob: as me, bob (not the chair), I don't see what the point of proposal 2 is
... it says too much and too little

ram: i'm willing to work on it some more and try and come up with another proposal
... i'm open to the possibility

bob: i have to ask "is this your final answer" at some point
... i'm tempted to do that now
... unless there is a willingness to move, in some specific way, to a consensus
... where is the willingness to move in a specific direction that will get us to consensus?

ram: you are asking me if i am willing to move in a direction to achieve consensus?

bob: yes, and what is it?
... (this specific direction)

ram: i have moved a long way from where i was weeks ago
... i'm willing to move further
... so we can all be happy

bob: how close to CWNA are you willing to go?

ram: CWNA is unacceptable

bob: that's not the question, how close to CWNA are you willing to go?

ram: CWNA is unacceptable

bob: right now your proposal is not as broad as the current specification

asir: can you elaborate on that?

bob: current specs says "messages must be of this form . . ."
... proposal 2 only addresses a subset

asir: it's not a replacement, it's an addition

bob: if proposal 2 were additive, would you be fine with that
... do we have a deal?

tom: no
... we don't need anything

bob: do we have two imovable objects?

asir: i don't understand tom

bob: tom said "no", as a person that writes profiles etc., proposal 2 wouldn't be relevant to the actual test assertions that would be written

asir: this sentence doesn't add anything new

bob: if it doesn't add anything new, why do we need it?

asir: ram said he needs it to clarify things

bob: everybody is saying that it adds nothing

<asoldano> ok

bob: permission to extend for 10 minutes

<fmaciel> need to drop

asir: i have another meeting to go to

bob: let's vote right now

asir: we've come up with another proposal (in our discussion)
... adding proposal 2 to the existing text

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

asir: some members have already left the meeting so I am not sure if we can vote

bob: we don't have quorums in W3C

redhat: CWNA

oracle: CWNA

microsoft: proposal 2

ibm: CWNA

fujitsu: CWNA

hitachi: CWNA

software AG: abstain

avaya: proposal 2

yves: proposal 2

bob: vote is 3 to 5 (proposal 2 to CWNA)

<dug> g'nite

resolution: 7015 is CWNA by vote

- DRAFT -

Web Services Resource Access Working Group Teleconference

27 Oct 2009

Attendees

Contents

agenda

minutes

F2F logistics

new issues

issues with proposals

7586, 7588, 7828

7911

7015

Summary of Action Items

Scribe.perl diagnostic output