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

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

From: Pete Wenzel <pete.wenzel@Sun.COM>
Date: Mon, 13 Mar 2006 19:50:56 -0800
To: Bob Freund <bob@freunds.com>
Cc: public-ws-addressing@w3.org
Message-ID: <20060314035056.GA6741@seebeyond.com>

> 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).

    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.

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.

Jonathan: Really blew away our requirements.  Lots more green in the
report than expected.

Glen: Concerned about orange boxes that show the minimum required

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:
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

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

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

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

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

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

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

No objections.

RESOLVED: Delete ProblemHeader element from schema; keep the same

> - Jonathan re Comparing IRIs

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

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

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?"

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

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

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

> 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

> * 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
> Nortel
> Sun
> webMethods
> WSO2
> JBoss
> Sonic
> W3C
> BT
> CA
> 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 07:32:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:13 UTC