See also: IRC log
<bob>Hearing no objections, agenda approved
Approved, including updates requested by David Hull.
2006-03-02: http://www.w3.org/2002/ws/addr/6/03/02-ws-addr-minutes.html
2006-03-03: http://www.w3.org/2002/ws/addr/6/03/03-ws-addr-minutes.html
More review time requested; not due to concerns about recording of resolutions of CR issues, but rather to ensure that the sense of conversations was captured accurately.
Approval deferred.
2006-03-03: Jonathan Marsh to Send email to John Kemp indication
> WG reconsideration and action of CR3 PENDING
(To be discussed under CR Review Comments agenda item.)
2006-03-03: Hugo Haas to draft mapping to CM of UsingAddressing.
> PENDING
Hugo: Present focus is on PR document editing; prefer to have this item reassigned if needed before next week.
Tony: Delay on this is ok. lc116 is more pressing.
Status remains PENDING.
PaulD: Had call on Tuesday. 6 hours of interop testing. Report is looking good. Concerned that there weren't enough correctly interoperating implementations at F2F, but now we have 6-7.
Bob: On track for PR?
PaulD: Believe so. Jonathan produced a nice-looking report. http://www.w3.org/2002/ws/addr/testsuite/report/
Jonathan: Really blew away our requirements. Lots more green in the report than expected.
Glen: Concerned about orange boxes that show the minimum required pairs.
Jonathan: Identified these on a first-come basis. Not strictly necessary, but was perhaps an incentive.
Hugo: Wish to congratulate everyone who took part. This will easily show Director by how much we exceeded our requirements.
RESOLVED: PR Test Criteria "to demonstrate four interoperable implementations during the Call for Implementations for the Core and SOAP binding specifications" has been met.
NOTE: Highlight overachievement of test criteria.
Review comments received:
Hugo: Director needs to be aware of any unresolved issues. CR3 was John Kemp's request to use extended ID to identify WS-A constructs for use by security extension. Current text implies that use of xml:id is allowed; suggestion is to strengthen this to a SHOULD. Director does not require this change. Personally like it, since xml:id is a W3C REC, as opposed to wsu:id.
Tony: Believe it is an improvement.
DaveO: Issue with difficulty this may cause with (default) canonicalization. If people use xml:id, we may have security problem because canonicalization will cause failure.
Jonathan: Bug is that xml:id is propogated to all child elements.
XML Core is producing Canonical XML Version 1.1 to deal with this problem.
PaulD: WS-I BSP requires Exclusive Canonicalization to avoid this.
DaveO: It's clear that we're not ready to resolve this immediately; requires further information and research.
Jonathan: Can live with either solution, but it should not hold up progress.
Bob: Does group wish to close with no action?
No objection.
RESOLVED: CR3 closed with no action.
Hugo: This binding document is to be published as a WG Note. In Status section, need to customize the boilerplate text, including what to do with comments. We have not discussed this yet. Think the best thing to do is to direct comments to our usual list. We can consider all comments received before publishing a final document. So, first publish a WG Draft, announce review for 4 weeks, then dispose of it as a WG Note.
Bob: Can the document location remain stable throughout this process?
Hugo: The mention in SOAP Binding PR spec is only an informative reference. By the time we get to REC, we can update the final reference and status.
Jonathan: If it has a "latest" URI, we can just use that. Any impact on the PR schedule?
Hugo: None.
Bob: How long for comment period?
Hugo: Believe it is 3 or 4 weeks; same as PR.
Jonathan: Need to coordinate with XMLP WG.
DaveO: Note that many active WSA WG members are also members of XMLP WG, so expect coordination to occur quickly.
No objections to accepting Hugo's proposal.
RESOLVED: Publish R-O-R Binding spec for comment; coordinate with XMLP.
Jonathan: Spec says we intend to keep namespace the same, unless there is a substantial change to the namespace. Believe the note should be removed. MarcH wondered whether we have indeed made a substantial change.
MarcH: We removed an element from the schema; does this require us to rev the namespace?
Jonathan: Propose that this is not a significant change. Doesn't affect implementations; the change actually makes the spec match implementations.
Hugo: Agree.
Tom: We could deprecate the element by leaving it in the schema, and adding a comment that it was removed from the normative spec.
Jonathan: Good suggestion.
MarcH: Prefer to delete it.
Bob: Propose to delete ProblemHeader element from schema, keep same namespace.
No objections.
RESOLVED: Delete ProblemHeader element from schema; keep the same namespace.
Section 3.2.1 needs to accommodate detection of "none" URI, in addition to "anon".
MarcH: Need to be careful about touching the issue of comparing EPRs again.
DavidH: Better to do it from a clean slate, but ok as it stands.
Jonathan: Probably won't have an impact.
No objections to closing with no action.
RESOLVED: Close, no action.
Jonathan: We reference 2nd Editions of most RECs, except for Infoset.
Believe this is an editorial oversight. Any reason for this?
Hugo: Usually make sure we point to latest versions. Agree that it is an oversight.
RESOLVED as proposed.
ACTION: Hugo to update Infoset reference to 2nd Edition, and any other stale references.
Glen: This was a result of testing. When duplicate FaultTo's present, our implementation would send to the 2nd one. Spec does not clearly state what to do in this case. DavidH noted that the spec used to have explicit instructions.
Bob: Recall extensive discussion on multiple FaultTo/ReplyTo/AckTo in January.
Glen: 2nd issue is regarding duplicate MessageId's.
DavidH: My pointer to February draft was in error; believe new text had since settled the issue. Don't try to constrain this further.
Re Glen's proposal to generate a RelatesTo for each MessageId: ok.
Propose to close with no action.
Glen: One test in Test Suite depends on how you interpret this case.
DavidH: Propose that if multiple elements exist for item with cardinality 1, the abstract property is undefined.
Glen: Agree.
DaveO: We have a fault for this case.
Glen: Also stated that in my mail. This is an edge case, but believe it does not need to be resolved.
Specific text from Glen's first mail in this thread:
End of the last paragraph in section 3.2: "In that case, any duplicated headers MUST NOT be used to populate the appropriate MAPs - the MAPs should be interpreted as if no such headers were present."
Also 2 editorial changes, to insert section headings:
"3.2.1 Sending Messages" and "3.2.2 Receiving Messages".
MarcH: Which document does this go in?
DavidH: 3.2 of Core talks about the infoset.
Glen: SOAP Binding document.
MarcH: OK, but doesn't flow well.
Bob: Is this important enough to close right now? If so, need to take the time to wordsmith.
Jonathan: Ambivalent.
MarcH: Is the really something that causes implementation bugs?
Glen: Yes, it occurred during testing.
Glen: [Proposes slightly modified text....]
Jonathan: Can we limit the fix just to duplicate FaultTo's?
Glen: No, it should apply to all similar duplicates.
DavidH: Does it have to be a "MUST NOT", or is a non-normative note ok?
MarcH proposes:
"A recipient MUST generate a wsa:InvalidAddressingHeader (see 016.4.1
Invalid Addressing Header) fault if such a message is received and any
header with an incorrect cardinality MUST be ignored."
Jonathan: Is ignoring it the same as not populating the property?
Would rather talk in terms of not populating the property.
MarcH's modified proposal:
"A recipient MUST generate a wsa:InvalidAddressingHeader (see 6.4.1
Invalid Addressing Header) fault if such a message is received;
headers with an incorrect cardinality are not used to populate the
corresponding abstract properties."
Tony: Suggest "MUST NOT be used", rather than "are not used".
Final proposed text:
"A recipient MUST generate a wsa:InvalidAddressingHeader (see 6.4.1
Invalid Addressing Header) fault if such a message is received;
headers with an incorrect cardinality MUST NOT be used to populate the
corresponding abstract properties."
Glen: Wish also to include section headers "Sending Messages", "Receiving Messages".
No objections.
RESOLVED: Above text and section header additions accepted.
Bob: Agree to take Core and SOAP Binding to PR?
No objections.
RESOLVED to request PR for Core and SOAP Binding.
Bob: Transition call is scheduled for 16th.
Hugo: Yes; will send out publication request by tomorrow.
Bob: Congratulations to everyone; two down, one to go.
Hugo: Just spoke with Ian Jacobs re R-O-R Binding reference; he suggested we link to latest version, but only republish if substantive changes are made in response to comments. No formal comment period.
No objections to this modification of previous resolution.
RESOLVED: SOAP Binding spec to reference latest version of R-O-R HTTP Binding spec; the latter to be republished only if substantive changes made.
* lc112 - Three states in two
Remains open, pending completion of Hugo's action item regarding this issue.
* lc117 - Why are the WS-Addressing WSDL binding elements capitalized?
Jonathan: They are in consistent style. Propose no action.
"Thank you for comment, style is consistent, and extent of change is unacceptable at this time."
No objections.
RESOLVED to close lc117 with no action.
ACTION: Bob to respond to lc117 commentator as noted above.
> lc116
"Section 4.3 defines the use of <wsa:ReferenceParameters> but does not say how this affects the WSDL 2.0 component model."
Tony: Propose to push Section 4.3 of WSDL Binding spec down a level to become 4.3.1; add Section 4.3.2, "WSDL 2.0 Component Model Changes".
MarcH: That would be the same as 4.2.3?
Tony: Yes.
No objection to acceptance of Tony's proposal.
RESOLVED: lc116 closed by adding WSDL 2.0 Component Model Changes section.
ACTION: MarcH & Tony to perform necessary edits for lc116.
None: adjourned at 2:40pm Pacific.