See also: IRC log
<trackbot> Date: 27 October 2009
<scribe> scribe: gpilz
bob: some probs getting it out so I
sent it directly
... everyone get it?
bob: minutes came out fairly
... anybody need more time for 10/20?
RESOLUTION: minutes from 10/20 accepted by UC
bob: Fredrick Hirsh contacted us
about XPath-subset for fragment specification
... they (XML Security WG) would like to caucus on 11/5
bob: 8 new issues
... any objection to accepting all new issues and assigning ownership to the raiser?
RESOLUTION: Eight new issues accepted
ram: I agree with this
bob: any objection to accepting this proposal
RESOLUTION: Issues 7586, 7588, 7828 resolved as proposed in http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0044.html
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"?
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
... limit to 2 times in the queue on each topic
tom: I was going to say the same
... 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
... 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?
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
(misc people have problem with "MAY generate")
ram: let's not worry about MUST or
... 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
... don't see why this case, out of all the possible error cases, should be singled out for special treatment
Bob: OK, lets talk about this at the face to face
bob: This issue has been around since
the 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
... 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> 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
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
bob: this looks like the proposal for
... omnibus proposal
... any objections?
gil: I object
doug: I don't see what this has to do
... 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
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 proposal?
<dug> "The Get request message MUST be of the following form:"
doug: I object; this is already in
... 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
Bob: doesn't that seem to be a shorter way of saying what you 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, could you clarify?
<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
... we should table this
<dug> MAY move on :-)
bob: there was no objection to
discussing this issue when we discussed the agenda
... let's continue
... is there anyone who would accept Ram's first proposal
wu: which one?
bob: (reads first proposal - see
... (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
... 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
... 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
... 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
... 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
... 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
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
... 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
... 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 from the Wg rection
... between 2 & 3, is there something we can put together?
tom: I think it's a waste of ink and
... 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
... 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: It 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
... trying to figure out if there is a constructive resolution that people can agree on
... 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
... folks agreed to the agenda
tom: nothing is going to change on
... 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
asir: yves said he wants to talk to gil and doug
bob: wasn't that concerning 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?
... is 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 the receiver behavior part?
bob: these issues seem to have
... 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
... 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 unless we chose to merge them
<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: Doug, you quoted the text that says "messages must be of this form . . "
<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?
... ram might find a new angle
bob: ram, do you have in mind new angle that you might be able to explore?
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
... 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 folks be fine with that?
... do we have a deal?
... we don't need anything
bob: do we have two immovable objects?
asir: i don't understand tom
bob: tom said "no, as a person that writes profiles etc., proposal 2 wouldn't be anything 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
bob: permission to extend the meeting for 10 minutes?
<fmaciel> need to drop
asir: i have another meeting to go to
bob: Then 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
microsoft: proposal 2
software AG: abstain
avaya: proposal 2
yves: proposal 2
bob: vote is 3 to 5 (proposal 2 to CWNA) EDITORIAL NOTE: CA who was on roll did not vote, was not preseent, and had identified no proxy
RESOLUTION: 7015 is CWNA by 5:3 vote