See also: IRC log
<scribe> scribe:TRutt
<scribe> scribe:TRutt
Jonathan stated that Microsoft has already implemented several of the FaultCodes that we agreed to eliminate on Thursday.
We agreed to put back DestUnreachable, ActionNotSupported, and EndpointNotAvailable
Katy asked if these had to be implemented to claim conformance
Bob F stated that they do not have a MUST constraint anywhere in the spec,
David: Implementation of these faults are optional (for the last three we are adding back in)
Agreed to add this note to the descriptions of each of these three faults
RESOLUTION: Insert after the description of "destination unreachable" action not supported" and endpoint not availalble, the following: "implementation of this fault is optional."
<Jonathan> http://www.w3.org/2002/ws/addr/testsuite/report/
Paul: we lost the asynchronous tests from SUN. The test implementations need more work.
<pauld> as does the report
<pauld> and collection of logs which are dip feeding in from various sources asynchronously
Jonathan: microsoft/IBM and IBM/microsoft, IBM/IBM, and microsoft/Microsoft are all OK.
Marc H: there could be a problem with the logs, our developers state the implementation is correct.
Paul: we could have problems with collecting the logs, or with generation of the report. Some of the "green" boxes could be wrongly idenfitied as well.
Jonathan: I do not think we have
fundamental issues.
... the biggest risk is that we do not have 4 complete
implemenations.
Glen: once we fix some of the AXIS problems, that could be fixed.
Paul: we might have 5 implementations, but some of the features may have a different set of 4 implementations.
Bob F: are there any changes which need to be made to the spec.
Paul: I do believe we have found the problems in the text already, and we have already reported those to the group.
Bob F: what remains is documentation of 4 interoperating implemtations for all of the test cases.
Bob F: would be good to have the test documentation completed by March 13 WG teleconf.
Hugo: intention to go to PR from the WG on March 13.
<Zakim> Jonathan, you wanted to close with no action
Bob F stated that the at risk feature for wsa:from has been stated by several groups as a feature that they have a use case for.
Paul D: none of the implementations have used this feature.
Paul D: My statement is incorrect. there are implementations which send wsa:From. We could add one test case to show that implemtatations can deal with it.
Marc G: since its optional we need two implementations to send it.
<pauld> notes that a test case could be 'don't bail on reception of a message with wsa:From' and then make sure three others interop with WSO2
Umit: I recommend that we close this issue with no change. Even though there is no explicit fallback to use of wsa:from in the behaviour text for replies, some users have found a reason to use this.
<bob> scribenick: TRutt
Jonathan: the spec has the field, but does not say what to do.
RESOLUTION: agreed to remove the "at risk" note from the CR text, and close the features at risk issue.
Glen stated that the axis implementation can generate the wsa:from element, and can do so for testing purposes.
Hugo: we should ensure that the complete implementations can all receive messages with all the optional features.
Paul D: we should add a test case which has wsa:from with mustUnderstand=true.
Hugo took the action to add the new test case for wsa:from generation with mustUnderstand=true
Bob F: this is a posponed issue on [Details] for wsa:ActionMismatch Subsubcode)
Dave H: add text to section 2.4 of soap binding- "This invalid addressing header fault MUST/SHOULD contain a problem action fault detail.
Jonathan: I do not think we need to do this, given the existing text.
RESOLUTION: agreed to close CR2 with no action.
<dhull> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000.html
<bob> This will be cr25
tile of issue Use SOAP 1.2 properties where possible in describing SOAP 1.2 behavior.
There were no objections to accepting the proposal, as an editorial change
RESOLUTION: accept D Hull proposal for CR25 as editorial change
John Kemp sent concern in email http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Sep/0002
Discussion led to conclusion that the original resolution was still acceptable to WG
Jonathan: we can point to the
existence of xml:id.
... there is no local id attribute because xml:id exists.
RESOLUTION: Editor will provide additional text pointing to existence of xml:id
Bob F: we need to have someone give a response to John Kemp
Jonathan took action to prepare response to John Kemp on our reconsideration of CR3
Bob F asked if there are any additional issues on the Core spec.
There were no further issues identified.
Bob F: since we have no further issues, we have to produce the final version of the docs to review, and recommend for progression to PR.
Glen: when will the formal objections be reviewed and resolved.
Mark N: the director has seen the formal objections, and has not sent feedback to the WG.
Glen: what message did he send.
Marc N: the messages was "yes you can go to CR"
Hugo: until we are in recommendation, the director can say we have to resolve a particular formal objection. Officially we have to wait to see if he will assert on these objections, which he has already seen.
Bob
Bob F asked if any companies change their allignment with either of the formal objections. No company wished to change their alignment.
Bob F asked the editors when they will have documents incorporating all resolutions.
Marc H stated the documents would be ready by the end of the day.
Bob F: I ask all members to review and send any coments before March 13. The intent is to vote to progress to PR at the March 13 meeting.
Hugo: we should publish the soap 1.1 note at the same time as the PR.
Bob F: Hugo will schedule a call with the Director after we vote to go to PR. The PR should be availalbe by the end of March, give a WG decision on March 13.
s/LC01/LC109/
D hull: you can leave the faultTo empty if you have a replyTo present.
Marc H: we need to clarify "either this or that"
Katy: the fault endpoint may be able to be derived by different means than presence in the request
discussion ensued on table 5-5
Marc H : suggest comgining reply endpoint and fault endpoint rows.
Dave H: for Table 5.5, and Table 5.7 , and Table 5.2, we can change entroy for fault endpoint to Y with asterisk, with asterisk pointing to reference to section 3 of core.
Anish: I prefer the merger of the two rows into "response endpoint".
Call attention to section 3.4 of core regarding the fault endpoint semantics.
Umit: I would rather not combine the two rows, I prefer Dave H proposal.
Jonathan: concensus that one of reply endpoint or reply endpoint properties should appear in table 5.5.
<TonyR> a/reply endpoint or fault/reply endpoint or fault/
<umit> i would really like an example just like Anish. Combination of the specs need to be illustrated.
Dave H: it should be clarified that for robust in only the fault endpoint defaults to the reply endpoint.
RESOLUTION: LC109 - at least one of reply endpoint or fault endpoint properties should appear in table 5.5, with some indication of the co-constraints in the core spec
Jonathan: this applies to table 5.6 and 5.8.
Marc: table 5.6 was the first place it applied.
Anish: what is good for reply is good for fault. We should not prohibit.
Marc H: you canot give a fault to a fault message in soap.
Tony R: all fault messages should have this note, not just the robust meps.
Dave H stated that we should not prohibit a fault to a fault.
<dhull> Just wondering whether it's our job to try to prohibit fault to a fault
Tony R: in 5.2.3 we do not distinguish fault.
Marc H: that is because it is an out.
RESOLUTION: LC110 agreed to be closed with no action.
Bob F: this came from the WSDL 2 group.
Hugo: the proposal is " Section 3.1.1 says:
A property of the binding or endpoint named {addressing required}
of type xs:boolean
should be phrased:
A property {addressing required} of type xs:boolean, to the
Binding and Endpoint components
Marc H: typically you put it on one place or another, not both
RESOLUTION: LC111 resolved by accepting Hugo proposal
Hugo: we need to enable three cases. So, it should be made clear that {addressing required} is an optional property, whose value is "true" if wsaw:UsingAddressing is present and wsdl:required="true" is present, "false" if wsaw:UsingAddressing is present by wsdl:required is not equal to "true", and not present otherwise.
Marc H: you either do or do not support addressing
Tony R: addressing required is a mandatory boolean property.
Anish: supported but not required forces a false value for "addressing required".
Glen: we could have values "none"
, required, and optional
... having two values "required" and "optional" for this
attribute.
Jonathan summarized on the whiteboard what we have today.
Jonathan: if using is on binding ti goes to both binding and endpoint. If using is on endpoint, it does not go to binding.
Anish: I like having the values "required" and "optional" string enumerations.
Jonathan: we need to clarify 3.1.1 to say what we want. I do not like calling these "required" properties. if the existence of the property depends on the syntax of "using addressing"
Tony: could be change "required" propety to "mandatory" property.
Jonathan: exisence of using addressing on binding results in the required attribute to be true in binding.
Anish: I do not understand what required means in this context.
Katy: I challenge our earlier decision to put using addressing on endpoint
<uyalcina> +1 to Katy
<anish> i see the following columns for the table: 1) what's in the syntax, 2) does the processor recognize the extension, 3) wsdl:required value, 4) property present in the component model 5) value of the property in the component
Jonathan: we can restrict the rules for bindings to be separate as for endpoint.
Anish proposed a table with 5 columns to express the semantics of using addressing to components.
Jonathan: we need to remove the word required in the text, and to have a link from binding using addressing to binding component, and another link form endpoint using addressing to endpoint component.
Group broke for lunch, to think about proper resolution for this lc issue
<Jonathan> Scribe: Jonathan
Marc has checked in draft PR docs.
Hugo will send a link to the snapshot to the WG.
Bob: before lunch, Anish was thinking of a table. Jonathan was talking about a list of actions to resolve this issue.
Jonathan: Proposal:
... Section 3.1.1: remove the word REQUIRED.
... Describe that UsingAddressing on Binding annotates Binding
component,
... Describe that UsingAddressing on Endpoint annotates
Endpoint component,
... Possibly note that both values must be considered to
determine whether Addressing is required for a particular
message.
Anish: wsdl:required should not
be used directly as the value of the property.
... Might want a different value set for the property.
Glen: Would be nicer if the
property existed or not, and then a separate property for the
value.
... If wsdl:required=true the value should be "required", if
wsdl:required=false or not there, the value should be
"optional".
Tony: I like "addressing support" with the possible values of "required", "optional", "not known"/"not supported"
Anish: If the sytnax doesn't
exist, you can still add the property.
... The processor doesn't understand addressing, it won't be a
property in the component model.
Jonathan: Be clear on component model - it's subtle.
Anish: Just change the naming of the property.
Bob: Regardless of the name, we have relationships. We need first to get relationship.
Tony: Want to allow the property appear even when there is no UsingAddressing extension.
Marc: Strange since you're telling people about yourself.
Tony: Want the third property to
encompass that there is no addressing support here.
... Not happy that absence implies it's supported.
... How can I describe the service as not supporting
addressing?>
Anish: We don't have such a marker.
Katy: Send a mustUnderstand="1" and get an error back.
<marc> can't imagine a service ever saying wsa:addressing_support="unknown"
Tony: Thought that was what the tri-state is about.
Marc: It really only has two states. You either require it, or you don't.
Glen: It says, I support, or you have to use.
Marc: You don't have to tell I support. No new information provided.
Anish: We have three states in
the value.
... and presence.
marc: But if it's not present, it's not telling you that the service requires addressing.
Anish: Maybe the service isn't telling you but it is still required.,
(don't go there)
Glen: Difference between
supported and required, and no indication.
... If you understand addressing, you've gotta do it.
Marc: from the services
perspective, you say UA=true when it's required.
... when it's not, you put it in or not.
... doesn't matter which.
Glen: How does that map to component model properties? Should be this addressing use property.
Anish: If you require addressing, you must put UsingAddressing in the WSDL?
Marc: Not that far, just if you require it and you want an interoperable mechanism, use this one.
Umit: Provision in WSDL for this marker. We went through this well in WSDL.
Marc: My proposal is equivalent to {prop}="true" or not there. "false" doesn't give you any other information.
Glen: "false" tells you that you
understood the marker at least.
... If you don't support WS-A in the syntax, you shouldn't
support it in the component model.
Jonathan: Thinks there is a difference. "False" means you can send the headers with mu and not expect a fault.
Glen: If you see this at the WSDL
processing time, I will know whether I can send those headers
or not. I might want to fault if the service doesn't delcare
support for WS-A.
... Tricky case is the optional one. We're overloading the
marker to mean "process the WSDL" and "allows WS-A".
... Once its in the component model, you're supposed to use
WS-A at that point.
Tony: wsdl:required is different than addressing required.
Glen: Those concepts do get confused, both in SOAP and WSDL. We've been trying to overload that.
<Zakim> anish, you wanted to ask marc how his view would look like in terms of the component model
Jonathan: Believe they collapse in practice.
Anish: Spec says if you put an
annotation in and say wsdl:required, it may change the meaning
of the element to which it's attached.
... The qname we've defined means that you have to use
addressing if required=true.
... We define the meaning of the QName.
Glen: It says the meaning of
[parent] might change when you understand [extension].
... in practice it works out Ok. It's your choice to
"understand" or not.
Anish: Can you translate how that translates to the component model.
Marc: Not up on cm speak.
Glen: If you don't understand the element you can't annotate the cm.
Umit: Provider puts the extension in. Client's perspective it contributes to the component model.
Glen: Choices are: understand the required extension or fault.
<anish> it turns out that it is not us who are getting confused about overloading wsdl:required. The wsdl spec says the following:
<anish> "A key purpose of an extension is to formally indicate (i.e., in a machine-processable way) that a particular feature or convention is supported or required."
<Zakim> marc, you wanted to talk about table 3.1
(scribe loses a bit)
Marc: I'm willing to change my
position. Spec says there are different requirements on an
endpoint depending on whether they've put this in the WSDL or
not.
... Table 3-1. Key difference is MAPs in input message.
... If you put it in, you have to accept addressing
headers.
... Component model does need to reflect tri-state.
Bob: Tri-state issue, seems discussion revolves around whether this.
Katy: Required/supported/not-known are the states in the table.
Glen: This is a problem with WSDL, I don't know what properties there are, what good does an abstract model do?
Jonathan: That's taken care of us by WSDL - read the Extensions part.
Bob: What's the proposal then?
Jonathan repeats. Essentially asking for a mapping of XML to component model.
Hugo: I proposed a mapping
originally, Marc said it duplicated a lot of things.
... Group said we can keep what we have.
Jonathan: Asserts that failed to
be clear enough.
... Would like to follow WSDL's style.
Bob: Fundamental objections?
Glen: Takes the WSDL required value rather than a different value.
Anish: Call it {addressing} =
"required
... " / "optional"
Glen: call it {using addressing}
Jonathan: Proposal:
<Jonathan> ... Section 3.1.1: remove the word REQUIRED.
scribe: Add mapping of XML to
component model
... Possibly note that both properties must be consulted.
... Change property name to {addressing}, values "required" /
"optional"
Glen: Namespace properties?
Jonathan: Didn't namespace the core WSDL properties. No framework for doing that.
Bob: Accept the proposal?
Katy: Looking at 3.2.1, might be impacts there.
Marc: Needs more editorial direction.
Hugo: I'll draft some text.
<scribe> ACTION: Hugo to draft mapping to CM of UsingAddressing. [recorded in http://www.w3.org/2006/03/03-ws-addr-minutes.html#action01]
RESOLUTION:
Proposal (see above) accepted as resolution of
lc112.
... and equivalent editorial changes to 3.2.1.
ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous
ACTION 1=Hugo to draft mapping of CM to UsingAddressing and Anonymous, and Action
http://www.w3.org/2002/ws/addr/lc-issues/#lc113
Hugo: This section should be
translated into WSDL 2.0 lingo (CM instead of XML)
... Also not too clear on where it is allowed, have to chase
references to intersect where UsingAddressing and soap:module
are both allowed.
... We should do the math for our readers. The intersection is
the Binding component.
Glen: Not on endpoint?
... Didn't we fix that at some point?
Hugo checks.
Glen: Need separate bindings for differnet module combinations? Too bad.
Bob: Objections?
Umit: UsingAddressing and soap:module have different expressive powers?
Glen: Researching a WSDL issue, we need soap:module at endpoint level.
Umit: Doesn't like this at the endpoint. Would rather we removed UsingAddressing at the endpoint.
Bob: Proposal acceptable as it stands?
Umit: Need to check editorially that we don't imply UA and module are equivalent.
Glen: Equivalent semantics, but not equivalent places you can put it.
RESOLUTION: lc113
closed by accepting Hugo's proposal
... plus editorial
check that we don't imply UA and module are completely
equivalent.
RESOLUTION: Fix
typos.
... lc114 closed by fixing typos.
RESOLUTION: lc115 closed by accepting fix.
Bob: Doesn't say how this extension affects the WSDL 2.0 CM.
Jonathan: Let's do it.
... property is a list of elements.
Anish: What about attributes on
the wsa:ReferenceParameters element? Are they lost?
... Isn't there a type for reference parameters already?
... So use the same type as the [reference parameters] property
in 2.1 of Core.
Umit: We discussed it, we just forgot?
Proposal: Add a {reference parameters} property to the WSDL 2.0 component model, with the same type as the [reference parameters] property in Core 2.1
RESOLUTION: lc116 closed with proposal above.
Bob: Call on the 13th is the last opportunity to touch the document. Our fundamental reason for the call is to pass the document off. The meeting will last as long as it takes.
Jonathan: suggests we require any comments to be accompanied with a complete and detailed proposal.
<pauld> +1 to Jonathan
RESOLUTION: Comments must be accompanied with a detailed proposal.
Anish: Once it goes to PR it's out of our hands.
Hugo: It's in my hands, so small changes (e.g. editorial) can be made as a result of AC or other comments.
Bob: Would like to hear from the
test group after the meeting on tuesday, if there are issues
that mean we'll slip the date we'll have to reschedule.
... No reason to hold the 8th call - cancelled.
... FTF in Cambridge, MA for May 4-5(?) by IBM.
... Pencil in the FTF.
Jonathan: Thinks we'll need it.
Bob: Don't buy tickets quite yet
though.
... This is your 8 week notice of the FTF. Possibility it might
be cancelled though.
Ajourned...