<anish> Scribe: anish
Mark: will go through the LC issues and if we have time will go through the WSDL issues
... + async TF report and discussion
Anish: what about the issue of splitting the WSDL binding doc?
Mark: W3C said that the WG may request it, but it will go to AC.
... Philippe said that it was a result of a compromise
anish: request for an agenda item for discussion of splitting of wsdl binding doc
mark: ok, we can discuss that
umit: what about the next f2f?
mark: lets discuss that tomorrow
jonathan: it might be better to talk about it today, as people might leave early. WSD WG may have a long concall in lieu of the F2F
... Glen had offered Boston (maybe)
<JacekK> Mark, could the issues list also be put in ~mnot/wsa/ ? 8-)
no objections to approving the minutes
minutes approved
Jonathan: this is a general soap problem. In Indigo, we plan to allow configuring the max soap message size.
... we can drop the first part
<pauld> sounds like ping-o-death .. 'soap-o-death'
Jonathan: the 2nd part is opening up lots of sockets. It is a general problem but before ws-addr there wasn't a way to do this
... this is still worth adding. we can decide whether we want to add this or not
marc: the last point is not just about faults but also replies
davidh: there is a general pattern, when someone gives u an EPR they are asking to send messages to that endpoint. There is trust involved there.
jonathan: we have a general issue about trust from marc
tony: don't run with scissors
anish: it is not necessary to have 'malformed messages'
jonathan: i don't think this is that important
mark: suggestion is to accept the last two sentences and add replies + removed 'malformed'
... any objections?
no objections
RESOLUTION: LC37 closed with the above resolution
Mark: this was from Nilo, we have accepted all the comments except #7
... we had asked Nilo to provide an example
Nilo: i haven't been able to do it, and i doubt if I can do that. So we should move on
Mark: any one willing to write the text?
... Proposal to close this issue with no action on comment 7
... any objection?
no objection
RESOLUTION: LC89 comment 7 closed with no action
Mark: we discussed this a bit previously. We did not come to a specific conclusion about it
... we had an action on it for Glen
... he is proposing that a note after section 3.4 in SOAP binding
jonathan: this is different than the issue
davidh: the main reason of raising this issue was that this could be done and had no idea if this was desireable
... we should say should or must
jonathan: we could do a should or must
hugo: i have an example where u do want to use this
... we exchange quite a bit of msgs. I sent someone the relationship and I want the relationship to be echoed back
davidh: if u want to pass info around u can define you header for this
anish: this is a general echoing mechanism and saying a MUST NOT is overly restrictive
... i may want to send the ACTION value cause it is required and without WSDL it is hard to get to
Katy: what is the client supposed to do when there is a conflict?
anish: well, it is a general issue about refps, but there is a conformance issue if the values in the EPR and the WSDL are different
glen: when we talked about issue 8 we talked about the idea that u as the sender of the message may care that someone has told you to put in GiveMeAllURMoney header
... it is ok for you to look in there based on the contact.
Hugo: katy gave the example of action, but we may create the problem as in issue 8. It is proper to have other specs to say something about headers sent thru refps.
... or should we put in text that provides priority
... this is a case by case basis and i'm not sure what we can say
Mark: i don't see any push back to glen's text
... any objection to accepting the text?
<mnot> http://www.w3.org/mid/80A43FC052CE3949A327527DCD5D6B270110C6BA@MAIL01.bedford.progress.com
<mnot> The insertion of SOAP headers into a message implies particular
<mnot> semantics. Since the reference parameter mechanism does not restrict
<mnot> the content of the generated headers, EPR suppliers should exercise
<mnot> appropriate caution to ensure their reference parameters do not cause
<mnot> unintended or erroneous semantics in the resultant SOAP message. For
<mnot> example, using a reference parameter to send a WS-Security header would
<mnot> be ill-advised (since other parts of the SOAP infrastructure will often
no objections to the above para
RESOLUTION: LC77 resolved by accepting the para above
Conformance Discussion
Mark: we have 6 issues about conformance
Mark: from prasad, have a couple of proposal
... he is asking for more specific stmts
... LC35 is from Jonathan. There is a proposal for this
... LC84 is about conformance of messages
... this is from DavidHull
DavidH: my suggestion is to be clear. The semantics are built around the idea of conformance message, but we don't define it
... 2 issues: can we tell what it means and can we agree on what it means
... this may well have overtaken cause of subsequent discussion
Jonathan: r u talking about msg in the general case (abstract case)
DavidH: i had thought of this as a Core stmt
... these are issues about the Core doc regardless of what we say in SOAP binding
Mark: we also have LC 85
... this is also about msg conformance
... We have LC82, which talks about processor faulting
... and finally LC62, which is Tom's issue about migration contract. We decided not to talk about this till we figure out the bigger compliance issue
DavidH: there are three/four diff levels of compliance that make sense
... we want to deal with compliant request msg, msgs that do have wsa headers but not in the right combination, full-request-reply all headers are present, no wsa-headers are present
Mark: jonathan sent a proposal on may 18th, which clarified the original proposal that he made
Jonathan: i would b happy to accept this revised proposal. The first issue we should take is what is a conformant message. There is conformant msg and there is SOAP conformant msg
DavidH: the model in the core is too restrictive
... we provide msg id for correlation. In particular binding we make restrictions. My proposal was to drop the MUST in Core
Jonathan: what specific small steps are there for us to go where we want to go
DavidH: one option is not to define what a conformant msg is
Jonathan: besides looking at each MUST, if u go back to issue 6 that points to the warning flags for Prasad and me
... we could just remove the stmt about conformance for messages in Core
... i might talk about conformance to reliability protocol and talk about conformance to ws-a in there
davidh: the main value is that here are some std headers and correlation
Jonathan: i prefer my proposal, but can live with davidh's proposal
... we should link testability and conformance together
davidh: we should talk about endpoint conformance rather then msg conformance
tomr: u need both
paul: i have been thinking about testing. i have been thinking of testing messages
<GlenD> U NEED BOTH
<GlenD> (egads, people)
<TRutt> Sender of a message must send conformant messages. Receiver of a message must also exhibit behaviour conformant to what the message contents requires to receiver to do.
<pauld> anish: don't think we're too far off. you can tell if a message is correct or not. you don't look at the message independent of the context. wrt endpoint conformance, you have to know the contract, e.g. WSDL,
<pauld> ... you have to know a lot more about the endpoint than addressing
davidh: we have 5 diff headers and 32 combinations. we have to specify what must happen and be explicit what we don't care about
... u test by sending 32 msgs
paul: u are asking for reference endpoints rather than test cases for messages
Glen: we specify both: structural constraint on the messages, we are also defining behavioral constracts
... it is a set of stuff that we want to support
... we should be able to test that set
... in CR we'll be testing the test scenarios
Davidh: we need reference test suites and not endpoints
... some set of echo operation
<umit> +1 to Glen
jonathan: i'm confused cause i hear david say that u want to nail down the behavior specifically, but at the same time u don't want use to say anything about behavior in the Core
davidh: i cannot look at the spec as it stands and figure out the answers for the 32 cases
... i would like precise specification and not many faults
... there aren't very many rules, we don't need a lot of machinary to do this
... there are three co-occurance restrictions that we move these constaints
... i have sent a proposal on the async list
... if we want to define a more general concept of req-res we can do that
... i'm more indifferent about where stuff is
jonathan: i would like to see specific changes to the spec
davidh: we can talk about taking all the MUSTs out of section 3.1 (the old section 3)
... strike the 'REQUIRED' in the abstract prop definition of [reply endpoint]
... strike the 'MUST' in [message id] abstract prop defintion
... strike the 'REQUIRED' in the abstract prop definition of [fault endpoint]
... section 3.3, i don't know what the 1st sentence means
Jonathan: we had a proposal to change that
Marc: the whole changes are making message id optional
davidh: if u want to specify a behavior that requires faults, we don't have the text right.
... jonathan is talking about what that means
Jonathan: my proposal is about SOAP, but i had a proposal to change the text in Core too
davidh: one reading is -- lot of don't cares. From conversations, it seems that the intention is to not do that.
Marc: the endpoint can do whatever it wants
davidh: but we have to say what it has to do when there is no conformant
jonathan: if a msg has wsa headers in it, then u check things and fault if not right
davidh: the text is not clear
marc: if u get a message that does not have any wsa stuff then we don't specify what the endpoint should do
davidh: we should specify for the 32 cases
... we don't say anything about 4 headers
... there is only one case where we say something -- definite semantics
jeff: there are 3 interesting cases: no headers, all four are specified, in between
... seems like we are safe if all four are specified. if none are specified if none are specified
... in the partial case, we can pick subset of these and specify
jonathan: we may not want to specify certain subsets
paul: i'm thinking of test cases and we can come up with test cases which bring out the ambiguity
... when u write the table, there will be several cells that are greyed out
Mark: we can address 6 and 35 with the text that jonathan proposed
... we also have 84 and 85 which is related to message conformance
... then we can look at 82 and 62. That is how i would like to proceed.
[BREAK]
<TRutt> ping
[back from break]
discussion of proposal from jonathan (in the soap binding)
mark: does this address LC 6 and 35?
jonathan: in addition to the text, there was removing 2 sentences (proposed by prasad) and use consistent term regd conformance/compliant
... does not address the strange terminology in section 3.3 in the Core
<scribe> ACTION: mark to look up on the 1st sentence in section 3.3 in Core (and whether we did anything regd this)
anish: little uncomfortable with the wsdl part in conformance section for soap
jonathan: me too, but could live with it
... paco wanted this
umit: without wsdl conformance how do we talk about endpoint conformance
anish: we can talk about wsdl binding conformance and if the wsdl contains soap bindings then it pulls in the soap conformance to ws-a and Core is always in play
... wrt to whether we want endpoint conformance independent of wsdl conformance, that is something to talk about
nilo: the last phrase about wsdl description, we can say that -- if there is a wsdl description it may pull in more conformance things from wsdl
mark: proposal is to close LC6 and LC35 -- using jonathan's proposal and remove the last part about wsdl and include things about wsdl conformance (which is a may), settling on compliant or conformant and weakening of the sentences (as pointed out by prasad)
katy: i want to ensure that one isn't required to send a fault when a non-conformant msg is received
jonathan: we don't specify when u formulate a reply
mark: any objections?
no objection
RESOLUTION: LC6 and LC35 are closed with the above proposal
DavidH: there is already text in the issues for changes (two options)
... my preference is option 1
... delete three 'REQUIRED' and move the remaining 'MUST/REQUIRED' to section 3.3
mark: proposal is to go thru all the abstract prop stmts and move things to section 3.3
katy: does this change the behavior
davidh: that depends on your interpretation of what it says now
jonathan: going back to conformance, it makes more sense to associate conformance stmt with the testable artifacts
... in soap binding we should say that when u conform to Core section 3.3 then u must do something specific
... i would like see a concrete proposal before i agree
... the second section in the 1st option does not define a compliant processor
<GlenD> +1 to Anish
anish: why don't we just move section 3.3 to wsdl binding
glen: what is a reply concept without an MEP concept
... agree with anish
mark: the proposal is to move all the imperative stmts and move to section 3.3 and then eventually move this to the WSDL binding
glen: there should be a single concept of meps across soap/wsdls and bindings and they should be able to layer things
... lets say the wsdl req-res is the req-res MEP, but this should be directly implementable with soap with and without ws-addr
... the general concept is that there a message that goes from node a to node b and node b needs a property to figure out where the following message is to be sent
jeff: what is the scope of abstract req-res? is this about architecture?
glen: yes, but don't want to use that term
anish: have an example in the core and point to wsdl but not define what a req-res is
<GlenD> ("that term" meaning "WS-* Architecture"... since that was a particular effort that has it's own implications)
katy: the only concern i have is (maybe not), if we leave the req-res out of the core does this cause a problem to folks like bpel?
glen: u need to define req-res somewhere, we could do it here, but what is in it right not is not clear
davidh: i'm in favor of moving this out to wsdl
... it makes quite a few issue that i have raised quite redundunt
marc: are we suggesting that we remove section 3.3?
mark: yes and move it to core. move stuff in section 3.1 to section 3.3 and then move section 3.3 to wsdl
marc: that is a bad idea
<umit> +1 to Marc
marc: we can remove the request-res from core, but we should not take this whole thing about formulating the reply and move it to wsdl
... then there is no point to core
umit: +1 to marc. In bpel, we need some guidance
jeff: if we remove some of the stuff what does the core mean?
... not testable
... my question is -- where is the concrete stuff that i can claim conform to
<pauld> it's a bag of properties
michael: can someone submit changes by email, can we then look at it tomorrow
... also these changes may affect going to LC again
davidh: +1 to anish, i am comfortable with defining abstract stuff only in core
... the wsdl doc defines how to define req-res
... why talk about just req-res, what about one-way and robust-in
vikas: the purpose of having conformance stmt in core is for new bindings that you create
... i don't look at core and say that an endpoint is compliant
... if i create a new binding then it should be compliant to the Core
paul: the purpose of core is that it is a bag of properties and how those properties interact
... conformance in the core is not useful
... we only have one binding, if we had another binding then it might help us understand
umit: it seems that everything has to be testable and since we cannot test the Core
... the core is somewhere in between and proposes guidance for request-resp which is different from wsdl req-res
... there is req-res that occurs as a composition
<bob> +1 to umit's point
mark: having the req-res in Core does not define the concept for everything
davidh: if we are trying to create a concept of req-res in general then it needs to be only as restrictive as necessary and no more
... we need to be careful about the rules that we have defined
jonathan: i think we should go for the minimal thing here. I don't think conformance stmt for endpoint makes sense. Conformance stmts about binding makes sense, but does not provide high value. The bidning specs will do what they do.
vikas: u have to say what minimal thing must be present to say that the message is using ws-addressing (and the specific binding)
jonathan: not much value
marc: +1 to jonathan
<umit> I actually did not want to say that everything has to be testable. I observed that the core can specify some general guidance/behaviour that you can expect.
marc: i still thing the core can specific some expected behavior, it is not expected that the binding should define this
davidh: we already talk about what to do with refps
... in section 2 we already say that echoing of refps is required
katy: i think the Core is a place to put reusable aspect of the spec. The notioin of req-res is reusable and should be in the Core.
jonathan: summary -- moving must stmts from 3.1 to 3.3, marc suggests that we reword section 3.3 and talks about reply messages, we haven't resolved anything about conformance
mark: we need to see a proposal
davidh: it needs to be clear when we are specifying behavior and when we are not
... we need to be clear what our scope
... is
anish: there is another issue of where section 3.3 should be, there isn't a consensus about whether it should be in Core or WSDL
mark: lets have folks work on a proposal during lunch and then we can discuss this during lunch
... two choices: do it after lunch or next week. Next week will mean we will lose context
marc: needs more time, hard to do during lunch
mark: lets try to do this over lunch and see if we can discuss this after lunch
[lunch break]
<bob> scribe: bob
<scribe> Scribe: bob
marc presented the re-drafts of section 3.1 and 3.3 of core that were accomplished over lunch
marc pointed out that there were major issues in this morning's discussion concerning conformance to core
<scribe> new language tightens up 3.1 and removes redundancy
this new text is intended to close lc84; David Hull indicates happiness with this conclusion
underlying issue remains concerning behavior concerning violation of cardinality as indicated in spec
pauld thinks one cannot be compliant to core, but must be compliant to a binding
core serves as guidance to binding writers
bob suggested that language be added that no binding may be constructed that violates the principles defined in core
Editors will augment text to enhance definition of cardinality notation as well as describing that derived bindings must not violate these constraints.
<pauld> how can you test my implementation represents action as 'string action' as opposed to 'string action[]'
<marc> i can test whether your implementation emits messages that contain multiple [action] MAPs
no,yes,no,yes,yes you can, no you cant;balderdash
The teacup was filled with a swirling mass of dense cloud; the strong arm of Zeus set forth lightning which struck throught the room
<pauld> chad, hi
question posed: conformance and cardinality
proposal is:that cardinality notation will contain a statement that statements will place constraints on bindings written to wsa core
formal vote: yes:10 no:6 abstain: 3 yes carries
Resolution: lc 84 closed without objection
<hugo> Yes: CA, Ericsson, Fujitsu, HP, IBM, IONA, Nortel, Oracle, SAP, Sonoa
<hugo> No: BEA, BT, Hitachi, Microsoft, Sonic, Sun
<hugo> Abst: Nokia, Tibco, W3C
concern expressed about behavior upon the receipt of a message that contains no addresing headers at all
<TIBCO-dmh> 0/x/x/x/x/fault
<TIBCO-dmh> x/0/x/x/x/fault
<TIBCO-dmh> x/x/0/x/x/fault
<TIBCO-dmh> 1/1/1/x/0/fault
<TIBCO-dmh> 1/1/1/x/1/OK
<TIBCO-dmh> and that covers everything
<TIBCO-dmh> however, we would like
<TIBCO-dmh> 0/0/0/0/0/OK
<TIBCO-dmh> and I would like to see a lot more "OK"
dmh has determined that the matrix is well formed
Resolution: lc85 closed with no action; dmh satisfied
Resolution: close lc82 without action
<Marsh> Append to the Conformance section: "Endpoints are allowed to continue to invoke operations outside the scope of WS-Addressing (i.e. omit WS-Addressing headers in response to messages that don't contain WS-Addressing headers.)"
<TIBCO-dmh> Endpoints MAY continue to accept and respond to messages which contain no WSA headers.
<TRutt> Conformant endporinta may omit WS-addressing headers in response tomessages that don't contain ws-addresssing headers.
<TIBCO-dmh> In the faults they MUST send back??
<TIBCO-dmh> Core should say "if no MAPs have values, no fault." SOAP should say "no headers means no values (i.e., no defaulting)"
<TRutt> Endpoints MAY accept and respond to messages which contain no WSA headers.
<TRutt> Endpoints MAY continue to accept and respond normally to messages which contain no WSA headers.
in new comformance section:
<mnot> Endpoints MAY accept and respond to messages which contain no WSA headers normally.
<TRutt> Endpoints MAY accept and respond to messages which contain no WSA headers.
formal vote on resolution to lc62
question is is mnot's text above acceptable to close lc62
<hugo> Yes: BEA, BT, Ericsson, Fujitsu, Hitachi, HP, IBM, IONA, Microsoft, SAP, Sonic, Sonoa, W3C
<hugo> No: Oracle, Sun
<hugo> Abstain: CA, Nokia, Nortel, Tibco
results yes: 13 no: 2 abstain:4
<marc> voted no because believe the problem should be solved in the broader sense rather than adding specific exception
break for 15 min; return at 3:45
resume at 3:52
<TIBCO-dmh> proposed request/reply rules from 7 April:
<TIBCO-dmh> All MAPs other than [destination] and [action] are OPTIONAL.
<TIBCO-dmh> If the request message defines a [message Id], the outbound message's [relationship] MUST contain the pair (in-reply IRI, ID), where ID is the [message Id] of the request.
<TIBCO-dmh> If the outbound message is a reply and [reply endpoint] is defined, the outbound message MUST be sent to the [reply endpoint].
<TIBCO-dmh> If the outbound message is a fault and [fault endpoint] is defined, the outbound message MUST be sent to the [fault endpoint]
<TIBCO-dmh> (optional rule) Otherwise, if a [source endpoint] is defined, the outbound message MUST be sent to the [source endpoint]
<TIBCO-dmh> (anonymous behavior)
<TIBCO-dmh> Otherwise, if the binding defines a default means of delivering outbound messages, the outbound message MUST be sent by that means.
<TIBCO-dmh> (and otherwise you're hosed) Otherwise, the message has been constructed inappropriately for the binding. It will not generally be possible to signal this at message delivery time, but there will have been enough information in the WSDL binding to detect the situation prior to message delivery time.
<TIBCO-dmh> EOM
mnot reads through a number of issues he thinks may be related
<umit> including the pergammon museum...
<TIBCO-dmh> (aka "the museum of mind-bogglingly large ancient things"
<TIBCO-dmh> )
discussion ensued concerning the replyto (1..1) requirement and the recommendation against that by the WSDL working group
<TRutt> Old suggestion "/wsa:ReplyTo
<TRutt> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous". Otherwise the [children] of this element convey the value of this property."
straw poll supported reopening i50; some concern about potential for delay; chair reopens issue with plea to limit debate
<Marsh> This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present.
<JacekK> the value of replyto is epr, not uri
<Marsh> Change to "This element MUST be present if wsa:ReplyTo or wsa:FaultTo is present, or if a reply is expected."
proposal: This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is "http://www.w3.org/@@@@/@@/addressing/role/anonymous".
mnot: as part of the resolution of lc84, there was an intention to remove five instances of MUST in the description of elements
<pauld> chad, glen thinks you pong :-(
<GlenD> This OPTIONAL element (of type wsa:EndpointReferenceType) provides the value for the [reply endpoint] property. If this element is NOT present then the value of the [reply endpoint] property is an EPR which contains only an <address> property, whose value is "http://www.w3.org/@@@@/@@/addressing/role/anonymous".
note that the presence of wsa:replyto does not necessarily indicate that a reply will occur
<pauld> s/^chad, .*$//
<jeffm> definition of new information from the process document:
<jeffm> The Chair MAY reopen a decision when presented with new information, including:
<jeffm> * additional technical information,
<jeffm> * comments by email from participants who were unable to attend a scheduled meeting,
<jeffm> * comments by email from meeting attendees who chose not to speak out during a meeting (e.g., so they could confer later with colleagues or for cultural reasons).
<jeffm> The Chair SHOULD record that a decision has been reopened, and MUST do so upon request from a group participant.
paco objects that anonymous is not the same as no value and makes no sense if there is no way back
<jeffm> and from the charter -- The Chair will: .. 3. Reconsider a decision only when presented with new information. (W3C Process Document, section 3.3.4).
Resolution: close without action lc83, dhull present
<scribe> ACTION: Marc Hadley to make a proposal on resolution to lc103
resolution to make editorial changes to section 3.3 wording concerning population of a reply message's message addressing properties to make sure it is clear that it is a new set of properties
Resolution: lc78 closed with editorial changes
adjourned 17:05