See also: IRC log
<TonyR> scribe: tonyr
Clarifying i56/i57
RESOLUTION: i56 resolved as MUST, not SHOULD
Wordsmithing the contents of 4.3 in WSDL document
disagreement on whether "include" makes order unimportant, or not
Suggestion that we may require a new CR issue regarding order
DaveH: will raise CR issue relating to this item
Revised text reads:
when present, the value of the [reference parameters] message addressing property for a message sent to an endpoint MUST
include each child element of the wsa:ReferenceParameters WSDL extension element.
RESOLUTION: i57 resolved with the revised text above.
Katy explains the situation
discussion of proposal 1
MarcH: do we think there are two separate action values, or is there one?
Jonathan: we decided there should be one
DaveH: are there potential issues when using an SMTP binding?
Jonathan: are you saying that proposal 1 is HTTP/SOAP centric?
discussion circling that question
DaveH: can we simply say "prefer the action in the binding" vs "prefer the action on the wire"?
Anish: does this only apply with UsingAddressing is present?
... if so, then WSDL with UsingAddressing is new, and should not contain conflicts
Others: but should be able to migrate WSDL just be adding the UsingAddressing marker
Anish: should fix up the WSDL when adding the UsingAddressing marker
MarcH: yes, it's a simple change, but requiring lots of people to change is not good
Gil: doing it Anish's way raises the barrier to migration to WSA for the masses - the only people who care are in this room
Jonathan: maybe we should let SOAPAction die out?
Glen: but sometimes we want the action outside the XML
<yinleng> Jonathan: Logical conclusion is loosening the requirement a little. To accommodate the goals, is to relax the restriction
Jonathan: introducing Proposal 3 - loosening the requirement that SOAPAction must be identical to [action]
PaulD: I have thousands of WSDLs - how much change must I make to them?
... not at all keen to hand-edit all of them
discussion of the implications to hand-editing - suggestion that tooling should fix these problems
PaulD: some web services implemented in Perl despatch on SOAPAction
<yinleng> Katy: I don't see it as a major hack
Jonathan: several ways to solve the problem
... 1. stop using SOAPAction
Hugo: want to speak against Proposal 3, for Proposal 1
... the definitions of the two seem to be the same
<yinleng> Hugo: This is about using an URI to identify the message
Gil: problem: SOAP 1.1 doesn't have defaulting rules, unlike WS:A
... where's the problem?
<yinleng> Jonathan: Nice to have a simple method to set the action once
Glen: we have all these rules that specify what to use for action in the absence of wsaw:Action
... if there is a wsaw:Action, then of course we use that
<yinleng> Anish: It is really a WSDL extension, a binding specific thing, a binding level extension
<scribe> Chair: let's drop Proposal 3
Proposal 1: 11
Proposal 2: 3
<vikas> proposal 1
<prasad> Proposal 1
<scribe> Chair: any objections to closing i65 with Prop 1?
<yinleng> No objection to proposal 1 being adopted
RESOLUTION: close i65 with Proposal 1
<yinleng> Break at 10:30
PLAN: break at 10:30, extended break to resolve network issues
CR9 relates to the Action for undefined faults
<yinleng> Hugo: Mark did a friendly amendment
Hugo: explains his concern about the use of MAY twice
Hugo dictates his suggested revision.
Jonathan: not keen on phrasing that suggests that all generic SOAP Faults must be defined in the WSDL - trying the discourage that in WSDL 2
MarcH: trying to state: use this Action for all addressing faults, for example
<yinleng> Hugo: When the value of the action property has not been defined explicitly, (for example, by SOAP Modules or by an extension such as the WS-Addressing WSDL Binding) the following value MAY be used:
Jonathan: this is intended to be used for generic faults, things one would not include in WSDL normally
<yinleng> Hugo: A bit confused about Section 5 of the SOAP Binding.
Hugo: willing to drop my version
<scribe> Chair: so we are left with Jonathan's proposal as amended by Marc H.
Jonathan: this is to be inserted in Section 5 of the SOAP Binding
Umit: why is a generic fault becoming an addressing fault?
Marc/Jonathan: no, this is the required action (required because we are using Addressing)
<yinleng> MarkN: Any objections to this as resolution to CR9?
<Tony> scribe: Tony
RESOLUTION: close CR9 with Jonathan's proposal as amended by Marc
Break now for 20 minutes - back 10:55 local time
We're back
Anish explains the issue
<yinleng> Tony: proposing wording already inserted in section4.2, SOA Binding
Anish: change SOAPAction HTTP header to SOAPAction HTTP Request header (two places), and change wsa:Action header to [action] property
<yinleng> Mark: Any objection to using this as resolution to CR11?
RESOLUTION: close CR11 with the revised text as above
DaveH describes the issue: question of whether the reference parameters are a list (order important) or set (unordered)
<scribe> Chair: so you are requested a statement in the Core stating that the reference parameters are unordered
DaveH: yes
<yinleng> Jonathan: Do we have to specify this? In what way will interoperability be affected?
<scribe> Chair: looking at the text in the Core document
GlenD: consider another spec which wants to sign the serialisation of the reference parameters - it would not work interoperably
<yinleng> Tony: We want to specify explicitly that it is not ordered
DaveH: suggestion - change opening statement in 2.1 under [reference parameters] from "a number of" to "an unordered collection of"
... [metadata] should change too
General wordsmithing
RESOLUTION: the WG clarified that the occurrences are unordered, and the editors will construct appropriate language to reflect this.
Chair describes the issue
<scribe> Chair: DaveO will be supplying a proposal, but it does not appear on the list
General discussion of the subtle change that was proposed during the last meeting
Jonathan: not keen on the strength of the language in the existing words.
MarcH: perhaps replace "is contrary to Web Architecture" with "is beyond the scope of Web Architecture"
TonyR: perhaps "is outside the scope"
General wordsmithing ensues
<vikas> Perhaps change "violote" to "does not conform" ?
<mnot> proposal:
<mnot> In the Web Architecture, resources are identified with URIs. EPRs whose properties other than [address] are used to identify resources which operate outside the scope of the Web Architecture, which may result in the loss of some of its benefits. When building such systems, care should be taken to weigh the trade-offs inherent in deploying resources that lose some benefits of the Web Architecture.
<vikas> But Mark they are in scope they just don't conform
<prasad> Other properties qualify the URI (address) that really identifies the resource?
Interchange of opinions faster than the scribe can capture them...
Chair makes a new proposal
<mnot> In the Web Architecture, resources are identified with URIs, which brings certain architectural benefits. EPRs whose properties other than [address] are used to identify resources lose some of those benefits. Therefore, when building such systems, care should be taken to weigh the benefits brought by non-URI identifiers against those brought by the Web Architecture.
Nilo: properties other than address aren't used to identify
Glen: a URL can be used in two ways - to identify, or not
<vikas> Are people deliberately eschewing the word "state". Cookies bring state so does wsa:ref
<scribe> Chair: seeing it from TAG's viewpoint, important to ensure that people realise that they "shouldn't do that"
<prasad> Isn't having operations other than HTTP GET, PUT etc. which most web services do, against web arch anyway? So does this matter?
Options:
option 0: do nothing - engage in discussion with the TAG: 3 votes
<vikas> option 1
Option 1: the TAG text: 6 votes
<prasad> option 2
Option 2: the new text (Mark N's latest version): 5 votes
<scribe> Chair: who cannot live with option 0?
TomR: note that the TAG text concedes that going another way may be beneficial
<scribe> Chair: cannot live with option 0?
Total of cannot live with option 0: 6 people
Total of cannot live with option 1: 4 people
Total of cannot live with option 2: a few (with exact text)
<scribe> Chair: there are suggestions to modify TAG text a little.
Modifying TAG text in small ways
interactive wordsmithing
<mnot> Chair: Mark Nottingham
<scribe> Scribe: Tony
Jonathan: still have a problem with the phrasing of "deploying resources not on the Web"
... makes it sound like you lose the benefits of the other items that are on the web
Straw poll: who wants the phrase "not on the web"?
Total: 3
who thinks we should not use this phrase?
Total: 2
Who cannot live with "on the web"?
<scribe> Chair: we'll fall back to using "on the web" for now.
Latest iteration of the text:
<mnot> Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] to identify resources is outside the scope of the Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the
<mnot> Web.
We'll leave CR10 at that point until DaveO is present
<vikas> I am here
<vikas> are you guys on mute
<Katy> Overload UsingAddressing marker to indicate async=full regardless of binding/protocol.
<Katy> New proposal for issue 59
<Katy> Overload UsingAddressing marker to indicate async=full regardless of binding/protocol.
<uyalcina> In the case of the WSDL SOAP/HTTP synchronous binding for request-response operations, the presence of the wsaw:UsingAddressing element does not change the requirement that the response message be sent over the same HTTP channel over which the request was received. In this case, the wsa:ReplyTo header in the request MUST NOT contain an address with a value different from the anonymous URI.
<dorchard> what's the uri for this proposal?
<uyalcina> Basically, we are proposing to change this paragraph to indicate that UsingAddressing semantics.
<dorchard> From the F2F agenda page at http://www.w3.org/2002/ws/addr/5/nov-f2f.html
<dorchard> Teleconference Bridge
<dorchard> TBD
<yinleng> MarkN: 3 proposals, one from Marc, one from Dave, and one from Umit
<uyalcina> umit+katy
<yinleng> Scribe: yinleng
<dorchard> What is the call-in #?
<GlenD> Zakim
<dorchard> #addr?
<dorchard> aha!
Marc: Presenting his proposal
Umit: Question on response binding.
Gil: Question on example v.
What is the significance on the Aysnc only element?
<dorchard> I lost everybody.
DaveO: E.g. v, two binding elements. Don't understand why there needs to be two binding elements to be used.
... Why do you need the second binding?
Marc: Bindings can specify a lot more than SOAP transports.
<TonyR> Glen: it would be nice to offer the ability to "derive" much of the settings from the original
<GlenD> Dave, the idea is that you might need to express MORE than just the SOAP transport binding... perfect example is what if I want the response to be delivered with the non-SOAP WSDL HTTP binding....
Anish: Made a suggestion that there are 3 different parts in this proposal.
DaveH: Seems like there are 2 proposals.
Hugo: What if your binding supports only 1-way messages? Want to send a message back. What do you do?
<TonyR> DaveO: question: looking at text here, doesn't seem to define sync / async
<TonyR> Glen: Anish was getting at that, too
Marc: Will use DaveO's definition of async.
<uyalcina> Anish has articulated my biggest problem with respect to the proposal.
<TonyR> Anish: did Marc consider correlating two one-way messages as an alternative to the strangeness that we see here?
Jonathan: Do we have consensus that we need to solve this problem of HTTP one way, and SMTP the other way?
<TonyR> Marc: didn't want to limit the solution to SOAP over HTTP - wanted to accommodate other protocols as well
<uyalcina> The charter does not require us to solve this
<dorchard> I think that multi-protocol is optional.
<TonyR> Marc: can do this with extensibility, but not keen on leaving it all to extension
<TonyR> Chair: everyone understands Marc's proposal?
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0014.html
<TonyR> DaveO presents his proposal
DaveH: We need to just allow for one protocol in and another protocol out, but need not limit it to HTTP and SMTP.
<TonyR> DaveO: note that there is no mention of asynchrony, nor of particular protocol bindings, in the description (3.1.1)
<TonyR> DaveO: using MEPs to avoid specifying things at the protocol level - this makes it protocol independent
Anish: Always never defined in terms of MEPs. Are you discussing in terms of SOAP MEP or WSDL MEP?
DaveO: Intended to be protocol MEPs
... Abstraction of protocol MEPs so that they are protocol-independent.
... request-optional response MEP is invariant of whether SOAP 1.1. or 1.2
... Example 3:5 shows accommodation of using HTTP one way, and SMTP the other.
... For the ability to switch response protocol, this Responsebinding will do it.
Hugo: Can you accommodate SOAP request on input, then response binding to XML over HTTP, but not SOAP?
MarcH: Maintain the QName way is more flexible than URI
... The SOAP over SMTP binding is written in terms of SOAP MEP. Is that one way or is that request-response?
<dorchard> [1] http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/att-0010/ws-addr-soapadjuncts-simplemeps_httpbinding.html
Take a 15 minute break now. Come back at 2:45pm.
Resuming now. 2:55 pm
<mnot> 4th proposal for i059:
<Katy> proposal 4: UsingAddressing marker indicates that supporting full WS-Addressing capabilities
Umit: Presenting proposal.
<mnot> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/att-0116/ProposalTake3.htm
<vikas> +1 on this proposal
Anish: Using addressing, in the SOAP over HTTP case, is there any implication wrt to where the addressing marker occurs?
Hugo: You are not talking at all about response binding?
Umit: Yes, we are responding to one of the three parts.
Jonathan: Is this behavior of the marker tied to the SOAP binding?
<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0026.html
Umit: With this proposal, this clarifies the SOAP over HTTP binding.
Anish: presenting his friendly amendment.
... This proposal is in the spirit of composability.
... Defines async as a hint to the wsdl processor that the request and response may be separated by large time interval, whatever large time interval means.
... Hints are important to know whether to generate a blocking model. Hints may be ignored.
... Proposal adds to Marc's propoal. Also adds to Umit's and Katy's, but not DaveO's which already covers it.
MarkN: This issue is more complex than "which proposal do people prefer". Should look at functionality provided by each proposal.
Discussion now on Requirements.
Resumption of questions for DaveO on his proposal as DaveO has rejoined.
<dorchard> the phone just muted.
Anish: How does one capture, in the SMTP binding, the property on the binding?
DaveO: This propposal is not meant to cover that scenario.
DaveH: How would you characterize the differences between your proposal and the other proposals?
Glen: Why do you need shim MEPs when you have got WSDL MEPs? Aren't these the same?
DaveO: No. Hoping to get rid of SOAP MEPs.
... Problem is SOAP MEPs as deployed in SOAP 1.2 are very constraining.
<TonyR> DaveO describes how he is eliminating the problems of SOAP MEPs through his new MEPs
<TonyR> DaveH: so you have both WSDL MEPs and protocol MEPs, both of which can be non-trivial
<TonyR> DaveO: yes
DaveH: Is this a discussion we should have, how many levels of MEP, etc. ?
<TonyR> DaveO: big advantage is eliminating the complexity of the SOAP MEP state machine
<dorchard> daveh, a key difference between the proposals is how many levels of meps, so how many levels is by definition in the discussion.
Resuming discussion on "i059 Decision Points/ Requirements"
1. Does async need to be controllable at the abstract level?
<uyalcina> Dave I just sent you the proposal 4, you are ahead of the group.
2. Does async need to be controllable at the binding level>
3. do we need the ability to specify binding details for responses?
4. What granularities (message, operation, etc.) does async need to be controllable at?
<dorchard> got the proposal, thanks umit!
5. How do we express async in terms of SOAP / Underlying protocols?
Change 4 to 4. What granularity of attachment (message, operation, etc.) does async need to be controllable at?
6. What async modes do we want to enable (always, never, optional, etc.)?
Removed 2.
<dorchard> 2: binding uri; 3: binding qname. :-)
Replacing 2 with 2: Do we need to be able to enumerate possible underlying protocols for responses?
Replace 3 with 3. Do we need the ability to parameterise binding details for responses?
7. Should the semantics of usingAddressing be defined in terms of a specific WSDL Binding (e.g. the SOAP binding)?
<dorchard> DavidHull, I think there is a question about what is the dependency between the usingAddressing and the contained binding or a referenced binding within usingAddressing.
8. Do we have to define complete async semantics for anything beyond SOAP /HTTP?
<mnot> cr10 proposal:
<mnot> Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] to identify resources is outside the scope of the Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the
<mnot> Web.
<dorchard> Thus, use of the abstract properties of an EPR other than [destination] to identify resources results in resources that are not on the web.
<dorchard> Thus, use of the abstract properties of an EPR other than [destination] to identify resources results in resources that are not on the web.
<dorchard> Thus, use of the abstract properties of an EPR other than [destination] to identify resources results in resources that may not be on the web
<mnot> Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than [destination] for identification may result in resources that are not on the Web. In certain circumstances, use of such additional properties may be convenient or beneficial. When building systems that use non-URI identifiers, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the
<mnot> Web
RESOLUTION: Approved minutes of the Oct 31 meeting.
<dorchard> DaveO's proposal: 2: yes; 3: no; 4:? 5: at the protocol mep level; 6: all modes; 7: no; 8: yes.
Discussing answer to question 2
Straw poll on question 2
<vikas> abstain
Yes - 7
No - 3
Q2 result - YES
Discussing answer to question 3
Straw poll on question 3
<vikas> yes
Yes - 5
No - 3
Yes - 6
<dorchard> who's voted no?
Q3 result - YES
Discussing answer to question 4
Replacing 4 with 4. Does async need to be attachable at operation level?
Straw poll on
Yes - 7
Rest are abstention
Discussing answer to question 6
Q4 result - YES
Replacing 6 with 6. Do we want the service to assert control over synchronicity?
<dorchard> there's 6a) service can say anonymous only; 6b) service can say non-anon only; 6c) complete client control (status quo).
Straw poll on 6
Yes - 5
Yes - 7
No - 5
Q6 result - yes (?)
Discussing answer to question 7
Discussin answer to question 8
<dorchard> I believe we must talk about words like "The âfullâ value indicates that either one or two protocol message exchange pattern (proposed in [1] request-optional-response MEP or in [2] as SOAP-request MEP) instances is used to transmit the request and response. " now.
Straw poll on 8
Yes - 2
No - 2
Has this discussion enlightened anyone or confused?
Straw poll on question 1
Yes - 3
No - 3
mnot: Try to eliminate at least one proposal tomorrow.
<vikas> are we done?
<vikas> bye
Meeting adjourned till shortly after 9 am tomorrow.
<dorchard> ogenki des ka?
<dorchard> Hai, so des ne?
<Katy> scribe: Katy
DavidH: Suggested slight change to 2nd sentence 'may result in the resource not being on web'
Hugo: TAG were stressing that Web architecture should use URIs to identify. New version is too watered down and lost TAG message
... Would like to see Web architecture mentioned in 2nd sentence - to indicate use of EPR abstract properties to identify resources outside scope of web architecture
(this is what was in previous version yesterday)
Jonathan: agreed
David: Against Hugo's proposal - where is the 'scope of the web architecture' defined
dorchard: this is not outside the scope of the web architecture - the term 'on the web' is preferable as it is a defined term which we can concretely say
<dorchard> http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-benefits
jonathan: If Web architecture is a spec then it's resaonable to define Web architecture but otherwise more abstract definintion
dorchard: 'on the web' is more specific - not dealing with abstract notions. Can live with stronger statements though
... 'on the web' = URI which is gettable
jonathan: Concern of TAG is non-HTTP gettable resources
Jeff: +1 for initial proposal - clear
Paul: TAG are doing a lot of work for us which will bring benefits. Would like to change wording slightly to focus on identification with URI vs identification with EPR
Mark: HTTP forms has same issue with identification but isn't 'contrary to the web architecture': Is this the issue here?
<scribe> Chair: Mark
General discussion on how to say EPR abstract properties lose benefits of Web architecture
<abbie> can u have the proposals on irc
4 proposals:
1 . From TAG
2. ... Thus, use of abstract properties .....for identification may result in the resource not being on the web...
3. ... identify resources is out of scoper of the Web Arch
<dorchard> What the heck, I'll vote for #1
4. ... id resources loses some benefits of the web arch
4. ... id resources loses core benefits of the web arch
<prasad> There are two (4.) above. Is that last one a 5.? or the real (4.)?
<TonyR> last one is the real 4
<vikas> vote for Proposal 2
<prasad> I vote for 4
Straw poll result: 1)=4 2)=4 3)=2 4)=7
<scribe> Chair: Can anyone not live with the 4th one?
<scribe> Chair: Take away and consider: we will chad later
<scribe> Chair: Summarised position from yesterday
<Gil> Please may I make a suggestion which might help us reach swifter resolution to the issues tomorrow?
<Gil> We have 4 possible proposals on the table:
<Gil> 1. (Initial SAP/Oracle/IBM proposal) Superceded
<Gil> 2. Marc's proposal based on 1+ Anish's friendly amendment
<Gil> 3. David's proposal
<Gil> 4. Umit's/my proposal
<Gil> Rather than discuss the above as complete proposals, could we separate into composable functions and discuss as such? I.e.:
<Gil> A. Specification of async only or sync only at binding level
<Gil> Should we opt for:
<Gil> asyncOnly attribute from proposal 2 OR wsaw:Async from proposal 3 OR no additional flag from proposal 4 (OR other)
<Gil> B. Specification of binding for async response
<Gil> Should we opt for
<Gil> wsaw:Async binding semantics from proposal 2 OR wsaw:ResponseBinding semantics from proposal 3 OR no response binding specification (OR other)
<Gil> C. Specification of async at the interface/op level
<Gil> Should we opt for
<Gil> Anish's friendly amendment to 2 OR no specification (OR other)
<Gil> There may be finer points that I have missed, but this structure might help focus the debate.
<Gil> Many thanks
<Gil> Katy
Umit: Compose complete proposal based on function
<bob> ping
<abbie> no
dorchard: Concern that it's not possible to separate A B and C above
<charlton> WG reviewing 4 proposals on the table vis-a-vis the i059 questions
Glen: A B and C will give framework
dorchard: agree but concerned that we may have problems with this approach
<scribe> Chair: A. Specification of async only or sync only at binding level
<abbie> +1 dorchard
marc: can't choose between asyncOnly and async without considering B
Katy: could we consider whether we need asyncOnly or synconly first?
dhull: change markup so we are saying 'I can acccept anonymous only'
... clarify concept - anonymousOnly (sync) NoAnonymous (async)
Tony: capability of the server rather than anonymous - tying to anon not good
Katy: Like to see requirement for sync only or async only
Anish: don't agree with Tony
<abbie> +1 Anish
Glen: leave async as that's what we understand.
... use case: sync - provides mechasism for partial support without having to have multi thread
use case: async only enables the service to never block
<Gil> +1 glen
Tom: sync only: migration use cases
dhull: Agrees with Tom and Glen
anish: don't think this is critical functionality. Issue is: is the service required to specify
dorchard: Service should be able to specify level of service that it supports. Currently we are client centered and this provides a mechanism for service to define its behaviour
... This is a useful mechansism to control behaviour of service.
katy: proposal 4 is not saying that implementations must be sync only or async only - could still use a fault
glen: agreed but would still vot e for sync/async service definintionto save runtime round trip to establish service capabilities
jonathan: +1 to Katy (proposal 4)
<abbie> +1 dorchard
Anish: if we decide to go with marker - shouldn't restrict the marker to request response MEPs - being able to accept anonURI (or not) is useful for other MEPs
Umit: Fault proposal should have been in proposal 4. Not required behaviour for service at this point
Gil: Disagree with 4 because problem should be addressed during development time rather than at runtime
dorchard: +1 Gil whole point is to specify contract as full as possible
tony: +1 to above
Paul: undecided - doesn't need to be done in wsdl
<abbie> +1 dorchard
dhull: wsdl marker mechanism to prevent fault from happening
<scribe> Chair: vote no flag v flag
<dorchard> Can we record the votes into IRC?
Result: YES (want flag) - 9 NO (no flag) - 6 Abstain - 2
<charlton> No formal objections
B: Specification of binding for async response
<PaulKnight> c u in 15
<PaulKnight> anyone there?
<PaulKnight> me too
<PaulKnight> is there another IRC going?
<PaulKnight> How are they running chad offline?
<PaulKnight> interesting conversations and plotting cabals
<PaulKnight> I think I see, local chad...
<bob> dave, we lost the line
<bob> will dial back in one
<PaulKnight> The BPEL point is good, could be nice to have a similar mechanism if these are really similar.
<PaulKnight> better hinting of smells than smelling of hints? or smacking of lunch?
<dorchard> do you know what time we are restarting?
<Jonathan_Marsh> dir
<mnot> Chair: Mark Nottingham
<mnot> http://www.w3.org/mid/436FD0D5.4030004@tibco.com
<pauld> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0037.html
<mnot> 1.We don't model this at the SOAP level.
<mnot> 1.We don't say anything at all about it. We talk about the WSDL binding, we mention the 202 rule in the context of SOAP/HTTP, and that's it.
<anish> Scribe: anish
<Jonathan_Marsh> We mention the issue, and mention that there are several possible approaches (see below), possibly include an editorial note asking for more input in LC, but don't commit to a particular approach.
Vote on whether the WG wants to go into specifying mapping of WSDL MEPs to SOAP/transport-level MEPs
<Jonathan_Marsh> 2. (DH1) We say that each physical exchange constitutes a complete SOAP MEP.
<Jonathan_Marsh> * If there is a fault, then the HTTP exchange is an ordinary SOAP request-response, with the fault as the response
<Jonathan_Marsh> * If there is no fault, then the HTTP exchange is still an ordinary SOAP request-response, with the 202 modeled as an optimized representation of a SOAP message with an [action] marking it as an acknowledgment. The email message is a SOAP one-way.
<Jonathan_Marsh> 3. (DH2) We say that each physical message is a one-way SOAP message exchange, distinguishing "SOAP/HTTP request" and "SOAP/HTTP response" as separate bindings of a SOAP one-way message exchange.
<Jonathan_Marsh> * If there is a fault, then there was a "SOAP/HTTP request" message and "SOAP/HTTP response" message.
<Jonathan_Marsh> * If there was no fault, then there was a "SOAP/HTTP request" message and a "SOAP/email" message. The 202 follows from a general rule of "send back 202 if you don't have anything else to send back."
<Jonathan_Marsh> 4. (UKA, if I understand it) We say that, in the context of async WSA, SOAP/HTTP can mean either what it already means, or it can mean send back a 202 and send the actual response some other way. We specifically define what this means if the response is sent through a separate SOAP/HTTP interaction, but not for other transports (i.e., we don't explicitly describe an email response).
<Jonathan_Marsh> 5. (DO, as I understand it). We model the HTTP exchange as an instance of a transport-level in-optional-out MEP, and the email (if it happens) as a transport-level one-way.
<vikas> vikas: Don't go there
Vote, don't go there: 9
go there: 2
abstentions: 4
Mark: we won't go there, lets look at #1
DaveO: i'm surprised that we are going to define a new binding
Glen: yes or modify the existing binding
umit: if you want to pursue option 2-6 you can still do it
glen: the problem is that when i want to do this with email then i have to do something else
anish: why is this a problem for SMTP
glen: cause i want to be able to compose one-way SMTP binding for req-res
marc: option 1 seems a bit odd, it says we don't say anything about it and then we go on to say what we are going to say
... we say things about 202 etc
daveh: by we don't say anything about 'it' I mean that we don't say what happens in all cases but only in the SOAP/HTTP case
marc: don't know how to include this in the wsdl-binding doc?
daveh: at sometime someone should spin up a framework. we are not prohibiting someone from defining a problem
... its just that we haven't nailed it down and therefore shouldn't be in the REC
Mark: do we have enuf information to close i059
... if so, i want to give an AI to someone to come up with a proposal
umit: proposal 1 (initial proposal) already addresses our decisions that we made today
anish: except the proposal is a soap1.1/wsdl1.1 specific thing
Mark: lets not get into syntax
hugo: we have another option to not say anything at all
Mark: the options are 1) we talk about 202 etc stuff, 2) 1 + add a ed note, 3) do nothing at all
daveO: i don't understand how the WG could realisticaly thing that it should define SOAP binding extension and smuggle them inside the WSDL extension. It should be a separate doc for this.
<uyalcina> It will take a while for Anish to scribe what he has just said, but a big +1
anish: would like to speak for 1. Keep it simple.
glen: mark the extension as required and that would be OK to do that.
... there is a spectrum between defining a 202 and defining a whole new binding
... would like to speak for 3
<uyalcina> i am very against option 3, we would have to define this in the testing framework. We will basically bless the behaviour in the spec if we go for 1. This is essential for interop,
gil: i'm a developer and dealing with WSDL and you want my tools to associate WSDL with my SOAP stack?
Marc: yes
glen: you already do that
anish: we define the extension and spell out exactly how it works for soap11/wsdl11 and let XMLP figure out their new binding for SOAP
Mark: are we ready to make a decision of 1 v. 3
... anyone object to 1?
One objection
Mark: lets take a vote
<vikas> vikas: Vote for 1
option 1: 5
option 3: 2
abstain: 8
Umit: this particular behavior is already in the test suite
Mark: it was asserted that all the decisions that we made are in proposal 1, is that true umit?
umit: yes
Mark: lets figure out the details on concall later and discuss testing for the rest of the f2f
--------------------
Break
-----------------------------
BACK
------------
Mark: we left off with original proposal 1
... umit can you walk us thru
umit goes thru the proposal
<discussion on umit's proposal>
hugo: in the proposal, you alternate between soap/http and soap1.1-http. which part applies to SOAP 1.1 and which part applies to SOAP 1.2?
umit: only applies to SOAP 11/http only. There is an open issues section
hugo: my 2nd question is: in the 'always' case, there is a MUST. Don't that mean that you need a wsdl:required='true'
umit: yes, probably
Mark: to move this forward, we need to refresh the proposal. Can umit/katy take an AI for that?
umit: is the request to rewrite it to make it more general or is it a rewrite for the next step?
hugo: i thought the attribute applied it to more generic and specify details for soap
Marc: if not we need to make the name more specific to http/soap rather then general 'async'
Mark: another thing is to start talking about SOAP 1.2 and WSDL 2.0
Umit: if you have specific problems with the text then pl. point them out
Mark: get a rewrite and then start generating issues about it, eg: do we need another fault? how to deal with WSDL 2.0/soap 1.2
... once Umit gets the new doc out, pl. identify the issue in the subject line of the email
<scribe> ACTION: Umit to rewrite proposal 1 [recorded in http://www.w3.org/2005/11/07-ws-addr-minutes.html#action01]
<scribe> ACTION: Umit to rewrite proposal 1 by 2005-11-16 [recorded in http://www.w3.org/2005/11/07-ws-addr-minutes.html#action02]
ACTION -1
Mark: is there anything we can do to move along SOAP 1.2/wsdl 2.0
hugo: we don't need to do anything about wsdl 2.0 and for soap 1.2 has a dependencies on XMLP
Mark: i would like to close this down soon, so review Umit's rewrite
... we only have i059 left. we have made significant progress on it. We have Core/SOAP in CR.
... we have closed all the known CR issues
... we may get one from the TAG
Umit: the SOAP faults should really live in the SOAP binding doc
Anish: there is a note in the SOAP binding CR doc about additional faults may be defined/changed. I hope that will allow us to define a new fault without going back to LC
hugo: i probably be ok
Mark: umit, why don't u file this as a separate issue
... to get out of CR, we really need to get this testing done
... my inclination is to still have an interop event
... when we are done with WSDL stuff we may have another interop
... some people may balk at 2 different interop events
... people can choose which interop even to attend
... vancouver interop/f2f is the week of 16th jan: tue-friday noon
... I hope to go to PR after the interop
... if we can be done with i059 we can get an LC doc before the holidays
<scribe> ACTION: Umit to file a CR issue about SOAP faults [recorded in http://www.w3.org/2005/11/07-ws-addr-minutes.html#action03]
<vikas> i am here
Paul: the testing effort is represented by the testing doc itself, which is quite up to date
... i think we should address is the list of testable features
... we don't have a feature about the metadata bucket
... we have test for all the the feature except core07, core08 and soap07
<pauld> walks through testable features: http://www.w3.org/2002/ws/addr/testsuite/features/
Paul: the feature list at http://www.w3.org/2002/ws/addr/testsuite/features/ is for soap/core doc right now
... there is no reason not to add additional tests if we can all agree to it
Mark: we can add more test and say that some test are required to exit CR and there could be more tests which raises the bar
Paul: there is an issue about IRI comparison tests
<vikas> going to drop off
Daveh: is this a testable feature
mark: can we drop core08 as a testable feature?
... we need a flag about whether it is core/soap or wsdl
... can we have a XSL view for various facets?
... lets drop core08 as a testable feature, we can still have the tests
Paul: we need something for optional faults
Mark: we need to have tests for fault semantics
... we need 2 impl. of this to get out of CR
daveh: do we have a test for each of the fault?
Mark: no
Paul: each test requires an example XML message and an xpath expression associated with it
Daveh: i had envisioned that u send a req that has a reply endpoint and that reply endpoint has some sort of complex context for which u should get a fault back
<jeffm> scribe: jeffm
mark: does anyone want to do the work on faults
... who will implement these faults?
... if two do not, (they are optional features) then we will have to consider dropping the feature from the spec
... wants to know if anyone knows at this point if they will implment these -- no answer yet
paul: each test has a "cost" -- need to be written and then reviewed to make sure the test is correct
... need to have at least one test per fault
mark: if it proves to be too difficult to test particular features, a possibility is to move that feature from core to a note
umit: volunteers to write some tests if paul will help to review and instruct
... why don't we split up the tests across wg members
daveh: doesn't quite buy have to have one test for all -- e.g. endpoint not avail --- is that really testable
paul: hugo submitted a test case -- one way message with none value for fault, but get a fault due to the way soap processing model works
... this part of value of cr, get feedback on fault design
mark: need to wait and see if any tests surface
... question: core07 -- will that be hard to develop a test?
paul: no -- just overlooked it
mark: strawman to move forward - test subgroup reg call 11 am PST
... as test group believes that they have a test completed can they bring it up to the WG for approval
jmarsh - in xmlp only issues that the test group couldn't resolve or had questions on went to the WG for review
mark: wants to make sure we make incremental process on the test suites, not wait until "the end" to have pushback from the WG
... are people comfortable with leaving it to the test group, and have the WG mainly control the Testable Features list
jmarsh: keep that list to what is required for CR, other desireable testing features should go into a different bucket
mark: 4 buckets for tests -- CR vs. extra and core/soap vs. wsdl
... what is process for deciding when something gets on the "official list"
... heavyweght -- WG approves every, lightweight -- WG only approves if their is a question on test group
... we will go with the lighterweight so -- WG members should track what the test group does, and bring up questions first with the TG
paul: not sure when we will be ready to really test --
mark: would be nice to have a web page providing instructions on how to run the various tests
... of the cos who have indicated they are going to test, can they provide a date for when they might be ready to start -- by jan
indication that 3 or 4 cos, at least, will be ready
paul: has developed wsdl 1.1 and wsdl 2.0 defs of test service -- feels pretty confident of the 1.1 wsdl description
not as confident that the wsdl 2.0 version is quite correct
paul: don't know how to describe soap 1.2 in wsdl 1.1 doc
mark: test telecon will happen next thurs
... no ws-addr telecon next week -- mark will be on vacation
... there will be a ws-addr call the monday of the week of US thanksgiving
... looking forward to a concrete proposal for i59
... AOB?
march: asks about resolution to issue 65 -- he sent an email
... 3 nov
... at end of email: subj Stable WSDL Binding Draft Available
... issue 63 (not 65)
... pushes back on issue -- will complicate the doc and require a lot of duplication
glen: why can't u define the xml mu -- and say in wsdl 1.1 do it this way, in wsdl 2.0 do it this other way
hugo: this methodology should be acceptable -- doesn't see any problem
no objection
mark: looking for a "bunny"
<scribe> scribe: you ask him what that means :-)
mark: bunny's task is to summarize the meeting results for wsdl WG f2f
glen: asks why the chair wouldn't do that?
mark: not my job
... is wsdl doc uptodate except for today's decision and i63
... asks katy and umit to present their propsal --- the price of success ;-)
mark twists their arms --
they agree
the crowd cheers
march followed by katy/umit will summarize the meeting for the wsdl jt f2f tomorrow
thanks to hitachi for hosting
<applause>
especial thanks to nishiyama-san
<more loud applause>