W3C home > Mailing lists > Public > public-ws-addressing@w3.org > March 2006

RE: Minutes, was Re: Agenda, WS-Addressing distributed meeting, March 13, 2006

From: Bob Freund <bob@freunds.com>
Date: Tue, 14 Mar 2006 04:08:07 -0500
To: "Pete Wenzel" <pete.wenzel@Sun.COM>
Cc: <public-ws-addressing@w3.org>
Message-id: <7D5D3FDA429F4D469ADF210408D6245A0390E4@jeeves.freunds.com>

Pete,
Thanks for Scribing
-bob

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Pete Wenzel
> Sent: Monday, March 13, 2006 10:51 PM
> To: Bob Freund
> Cc: public-ws-addressing@w3.org
> Subject: Minutes, was Re: Agenda, WS-Addressing distributed meeting,
March
> 13, 2006
> 
> 
> > W3C Web Services Addressing Working Group - distributed meeting
agenda
> >
> >   Monday, 13 Mar
> >
> >   21:00-23:00 UTC; 13:00-15:00 US/Pacific; 16:00-18:00 US/Eastern;
> > 21:00-23:00 UK/London; 22:00-24:00 FR/Paris; 7:00-9:00 (Tuesday)
> > AU/Brisbane; 8:00-10:00 (Tuesday) AU/Melbourne
> >
> >   Dial-in information on WG Admin page
> > <http://www.w3.org/2002/ws/addr/admin>
> >
> > 1. Roll call, select scribe
> > (see scribe list below)
> 
> These minutes taken by Pete Wenzel (Sun Microsystems).
> 
> Present:
>     Robert Freund (Hitachi, Ltd.)
>     Jonathan Marsh (Microsoft Corporation)
>     David Illsley (IBM Corporation)
>     Hugo Haas (W3C)
>     Prasad Yendluri (webMethods, Inc.)
>     Nilo Mitra (ERICSSON)
>     Paul Downey (BT)
>     Andreas Bjarlestam (ERICSSON)
>     David Hull (TIBCO Software, Inc.)
>     Tom Rutt (Fujitsu Limited)
>     Francisco Curbera (IBM Corporation)
>     Katy Warr (IBM Corporation)
>     Mark Little (JBoss Inc.)
>     Mike Vernal (Microsoft Corporation)
>     Pete Wenzel (Sun Microsystems, Inc.)
>     Vikas Deolaliker (Sonoa Systems, Inc.)
>     Yin-Leng Husband (HP)
>     David Orchard (BEA Systems, Inc.)
>     Glen Daniels (Sonic Software)
>     Tony Rogers (Computer Associates)
>     Steve Vinoski (IONA Technologies, Inc.)
>     Marc Hadley (Sun Microsystems, Inc.)
> 
> > 2. Agenda review, AOB
> 
> > 3. Call for corrections to the minutes
> >
> > - 2006-02-20:
> > http://www.w3.org/2002/ws/addr/6/02/20-ws-addr-minutes.html
> 
> Approved, including updates requested by DavidH.
> 
> >   - 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 sense of conversations
> was captured accurately.
> 
> Approval deferred.
> 
> > 4. Review action items
> > <http://www.w3.org/2002/ws/addr/admin#actionitems>
> >
> >     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.
> 
> > 5. Interop test report
> 
> 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.
> 
> > 6. Review of pr submission material
> >    Final corrections
> 
> Review comments received:
> 
> > - CR3:
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0033.ht
ml
> 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.
> 
> 
> > - SOAP 1.1 request optional response HTTP Binding
> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/att-
> 0006/soap11reqoptresphttpbinding.html
> 
> 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.
> 
> 
> > - Issue: Jonathan's message re CR namespace warning
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0050.ht
ml
> 
> 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.
> 
> 
> > - Jonathan re Comparing IRIs
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0053.ht
ml
> 
> 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.
> 
> > - Infoset reference
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0054.ht
ml
> 
> 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's issue, "Where do faults go?"
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0036.ht
ml
> 
> 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.
> 
> 
> >    Vote for submission
> 
> 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.
> 
> 
> > 7. Issues <http://www.w3.org/2002/ws/addr/lc-issues/>
> >
> > * 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.
> 
> > 8. Other Business
> 
> None; adjourned at 2:40pm Pacific.
> 
> > -----------------------------------------------------------
> > Scribe list
> >
> > A participant from the Member at the top of the list is expected to
> > scribe the meeting. If no participant from that Member is able to
> > scribe, a participant from the the next Member on the list is
expected
> > to scribe, and so forth. After one participant from a Member
scribes,
> > that Member's name goes to the bottom of the list.
> >
> > Systinet
> > Sonoa
> > Hitachi
> > HP
> > IONA
> > Nortel
> > Sun
> > webMethods
> > WSO2
> > JBoss
> > TIBCO
> > Sonic
> > W3C
> > SAP
> > BT
> > BEA
> > CA
> > IBM
> > ERICSSON
> > Oracle
> > Fujitsu
> > Microsoft
> >
> > Scribes, please see <http://www.w3.org/2002/ws/addr/minutes.html>
for
> > more information about taking minutes.
Received on Tuesday, 14 March 2006 09:08:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:12 GMT