- From: David Hull <dmh@tibco.com>
- Date: Thu, 23 Feb 2006 15:29:57 -0500
- To: Bob Freund-Hitachi <bob.freund@hitachisoftware.com>
- Cc: "[WS-A]" <public-ws-addressing@w3.org>
- Message-id: <43FE1B45.9040709@tibco.com>
Clarifications inline.
Bob Freund-Hitachi wrote:
> Are available for review at
> http://www.w3.org/2002/ws/addr/6/02/20-ws-addr-minutes.html and are
> attached for your convenience
>
> -bob
>
>
> ------------------------------------------------------------------------
>
> W3C <http://www.w3.org/>
>
>
> Web Services Addressing WG Teleconference
>
>
> 20 Feb 2006
>
> Agenda
> <http://www.w3.org/mid/7D5D3FDA429F4D469ADF210408D6245A03909A@jeeves.freunds.com>
>
> See also: IRC log <http://www.w3.org/2006/02/20-ws-addr-irc>
>
>
> Attendees
>
> Present
> Andreas Bjarlestam (ERICSSON)
> Glen Daniels (Sonic Software)
> Paul Downey (BT)
> Robert Freund (Hitachi, Ltd.)
> Hugo Haas (W3C)
> David Hull (TIBCO Software, Inc.)
> David Illsley (IBM Corporation)
> Anish Karmarkar (Oracle Corporation)
> Paul Knight (Nortel Networks)
> Jonathan Marsh (Microsoft Corporation)
> David Orchard (BEA Systems, Inc.)
> Tony Rogers (Computer Associates)
> Tom Rutt (Fujitsu Limited)
> Katy Warr (IBM Corporation)
> Umit Yalcinalp (SAP AG)
> Prasad Yendluri (webMethods, Inc.)
> Absent
> Abbie Barbir (Nortel Networks)
> Dave Chappell (Sonic Software)
> Eran Chinthaka (WSO2)
> Francisco Curbera (IBM Corporation)
> Vikas Deolaliker (Sonoa Systems, Inc.)
> Jacques Durand (Fujitsu Limited)
> Marc Goodner (Microsoft Corporation)
> Arun Gupta (Sun Microsystems, Inc.)
> Philippe Le Hegaret (W3C)
> Amelia Lewis (TIBCO Software, Inc.)
> Bozhong Lin (IONA Technologies, Inc.)
> Mark Little (JBoss Inc.)
> Jeff Mischkinsky (Oracle Corporation)
> Nilo Mitra (ERICSSON)
> Eisaku Nishiyama (Hitachi, Ltd.)
> Ales Novy (Systinet Inc.)
> Gilbert Pilz (BEA Systems, Inc.)
> Davanum Srinivas (WSO2)
> Jiri Tejkl (Systinet Inc.)
> Mike Vernal (Microsoft Corporation)
> Steve Vinoski (IONA Technologies, Inc.)
> Pete Wenzel (Sun Microsystems, Inc.)
> Steve Winkler (SAP AG)
> Regrets
> Marc Hadley (Sun Microsystems) proxy to Microsoft for cr20
> Yin-Leng Husband (HP)
> Chair
> Bob Freund
> Scribe
> David Illsley
>
>
> Contents
>
> * Topics <#agenda>
> 1. Agenda Review <#item01>
> 2. Call for Corrections to the Minutes <#minutes>
> 3. CR22 <#cr22>
> 4. CR23 <#item02>
> 5. CR18 <#item03>
> 6. CR20 <#cr20>
> 7. CR23 <#item04>
> * Summary of Action Items <#ActionSummary>
>
> ------------------------------------------------------------------------
>
>
>
>
>
>
> Agenda Review
>
> <dorchard> low turnout because of Pres' day?
>
> agenda approved
>
>
> Agenda Review
>
> *RESOLUTION: minutes of Feb 13th accepted*
>
>
> CR22
>
> Bob: New Issue cr22. Jonathan has provided a proposal
>
> Jonathan: Straightforward proposal - changes wording from MAY to SHOULD
>
> *RESOLUTION: Proposal 1 accepted*
>
>
> CR23
>
> Bob: WSRX had requested some changes around anonymous represented as
> CR4 which resolution was nullifed by CR15
>
> Umit: Joint proposal for CR20 contains fix for this.
> ... Should we wait for resolution to that
>
> Bob: Fine, keep CR23 open until after the CR20 discussion
>
>
> CR18
>
> Bob: Does proposal for CR20 cover CR18?
>
> Anish: CR20 Proposal 3 contains language appropriate to CR18
>
> Bob: Are people happy with Proposal 3 for CR18 at this time?
>
> <PaulKnight> Proposal 3: Clarify Status
> Quo<http://www.w3.org/mid/2A7793353757DB4392DF4DFBBC9522550276F310@I2KM11-UKBR.domain1.systemhost.net>
>
> dhull: Pauld's proposal says that anonymous has no semantics but in
> the response case we have a requirement to use it so there are some
> defined semantics
>
> pauld: That line has context as it appears after text describing
> sending messages down the back channel
>
> dhull: happy but wants some i-dotting and t-crossing
>
> Bob: From timeline standpoint, barring other long issues, nearly done
> ... Wants all but small cleanups done by end of next week
>
> Anish: Should we resolve CR20 before CR18?
>
> dhull: Can we leave text to editors discretion with paulds proposal
> and a note to editors to keep consistent with section 3.4
>
> Jonathan: ok withthat
>
> *RESOLUTION CR18 closed with proposal 3 with caveats - david hull to
> work with editors to modify text as necessary to keep consistent with
> section 3.4* (without objection)
>
> <dhull> new CR issue at
> http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000.html
>
>
> CR20
>
> Bob: CR20 Listening to debates. Decide to go down one of 2 routes...
> ... Close with no issue or editorial tweaks of the amalgemated proposal
>
> Anish: Proposal to combine proposals from Anish and Paco
> ... Removes defaulting from core
> ... specifies in SOAP spec that messages on the back channel must have
> anonymous as To and that it defaults to this
> ... Also includes wording similar to paulds proposal and specifies no
> additional semantics
> ... Also re-incorporates resolution to CR4. Editorial issues raised
> which Anish accepts
>
> Jonathan: Disagrees with proposal. Why are we bothering. Fears
> unintended consequences
> ... Defaulting per status quo doesn't bother me. Happy to close issue
> today
>
> <GlenD> Am fine with status quo myself.
>
> Umit: Jonathan, what issue do you think is lurking
>
> <GlenD> Esp if the representative from the company whose
> implementation had the problem thinks so. :)
>
> Jonathan: Seem to just be moving bits around between specs. Seem to be
> adding complexity
>
> <dhull> +1 to not mucking with default
>
> <dhull> -1 to referring to 3.4 as an obscure rule
>
> <GlenD> +1 - if you can't deal with anonymous, you simply ARE NOT
> going to give other people EPRs containing the anonymous address....
>
> <uyalcina> thanks
>
> Jonathan: Makes itmore complicated to have to refer to different specs
> to work out the defautlt value
>
> <hugo> +1 for status quo
>
> Jonathan: No major benefit for a big change
>
> Bob: How strongly do people feel about changing the spec like this?
>
> <dhull> also "such a channel" doesn't square with accepted CR 15 text
>
> Anish: Doesn't agree that this is a major change
> ... Defined anonymous as being something the binding defines. Since
> not defined in core need to look at binding anyway
>
> <Zakim> dhull, you wanted to talk about relevance of CR4/CR 15 issue
>
> dhull: Text of amalgamated proposal. Don't talk about back channel
> anymore - talk in terms of MEPs etc
>
> <anish> david, the editors can change the text to fit with CR15
>
> dhull: Anything we do needs to be in harmony with resolution of CR15
> and perhaps need to rexamine conflict between CR4 and CR15 before
> moving on. Proposal is perhaps too amalgemated
> ... would prefer to be more specific and just talk about defaulting
> when talking about CR20
>
> Anish: Text from CR4 included because I was surprised it was taken
> out. Acceptable to take that out and put it in the right context.
>
> <Zakim> pauld, you wanted to ask about use-cases
>
> dhull: Would like to have discussion separately and define term
> underlying response message
>
> pauld: agree with Jonathan. Thinks it is a big change, would change a
> reviewers experience
>
> <dhull> "underlying response message" is *nothing* new. It's just
> putting a tag on what we already figured out in CR 15.
>
> Tom: Want minimal change. Think that sentence from CR 4 should go in
> but separate issue. Best we can do is lots of wordsmithing but agrees
> with Jonathan
>
> Katy: Defaulting to anonymous may not be appropriate to all bindings
> so moving it from the Core makes sense
>
> <anish> i don't want to rehash my arguments for the default in core
> issue. Since I expressed them before. But is inappropriate to define
> an anon default in the core, when we don't even know what it means.
>
> <pauld> you can send To anonymous only if the service understands
> anonymous .. our spec doesn't give it any *special* meaning so I don't
> understand why defaulting it is suddenly interesting or useful or why
> we should make this change during CR
>
> Hugo: Agreeing with Jonathan. Close to PR. Should not be moving things
> around without good reason and full understanding. Supports the status
> Quo.
>
> <anish> +1 to not being myopic
>
> <anish> defaults have to be appropriate
>
> <pauld> thinks this will constrain future binding authors
>
> Umit: Net effect on functionality is same between status quo and
> proposal. Longer term view: Amalegmated proposal is better for the
> unforseen future. Unsure
>
> Tony: Thinks would be good to have a fault for 'you should have given
> me a wsa:to, not defaulted'
>
> <Zakim> Jonathan, you wanted to dispute long-term view.
>
> dhull: Defining Underlying response message is something we've
> discussed before
>
> Jonathan: Don't agree that this will help in the long term. Spoken to
> engineers working on new binding and like the defaulting of anonymous
>
> <uyalcina> My point is it depends on the binding. Therefore, it would
> be beneficial not to default it in the core.
>
> Bob: 2 alternatives: Amalgamated proposal or status quo, formal vote
> one per company please, Microsoft holds Sun's proxy on this one
>
> Anish: summary of propsal - remove defaualting from core. Add it to
> SOAP binding and say that message son such a channel must have
> destination of anonymous
>
> Formal Vote:
>
> *Formal Vote:*
> Votes in favor of closing with no change
> BT
> Computer Associates
> Hitachi Ltd.
> Microsoft Corporation
> Nortel Networks
> Sonic Software
> Sun Microsystems
> Tibco
> W3C
> Votes in favor of Amalgamated proposal
> Fujitsu Limited
> IBM Corporation
> Oracle Corporation
> Votes "Present"
> Ericsson
> SAP
> webMethods
>
> status quo: 9 proposal: 3 abstains: 3
>
> *RESOLUTION CR20: Close with no action*
>
> <TRutt> When will we add the text back from CR 4?
>
> <anish> tom, that is now issue 23
>
>
> CR23
>
> Bob: How do we regain text from CR4 that we lost in CR15?
>
> <TRutt> why not put the text back which used to be there
>
> Umit: No proposal about this. Seen dhulls proposal. Have several
> issues with it. Some clarity in defining HTTP back channel but
> requires more editorial work
>
> Tom: Anish, how much of the first paragraph from the proposal was fromCR4?
>
> Anish: Copied and pasted from CR4
>
> dhull: want to understand issue. Understand of CR4 is WSRX needs a way
> of saying Acks go back in response message
>
> <uyalcina> this is not the correct characterization of the problem...
>
> dhull: Think when it was first resolved added the vague language about
> back channel. This was clarified in resolution to CR15. Proposing
> defining the underlying response message
>
> <TRutt> Adding a new "special uri" at CR is too much
>
> dhull: Intent to wrap name around well understood meaning to make it
> resuable
>
> <TRutt> from anish proposal: 2) In the SOAP binding spec [2], in
> section 5.1 add:
>
> <TRutt> -----
>
> <TRutt> {The para below is the resolution text for CR4 and included
> here for flow}
>
> <TRutt> When "http://www.w3.org/@@@@/@@/addressing/anonymous" is
> specified as
>
> <TRutt> the address of an EPR, such as the ReplyTo or FaultTo EPR, the
>
> <TRutt> underlying SOAP protocol binding provides a channel to the
> specified
>
> <TRutt> endpoint. Any underlying protocol binding supporting the SOAP
>
> <TRutt> request-response message exchange pattern provides such a
> channel for
>
> <TRutt> response messages. For instance, the SOAP 1.2 HTTP binding
> [SOAP 1.2
>
> <TRutt> Part 2: Adjuncts] puts the reply message in the HTTP response.
>
> dhull: Want to build on CR15 and not lose that work
>
> <uyalcina> Thanks Tom. This was the resolution text
>
> <bob> ack anishq?
>
> Anish: Question for dhull: are you suggesting we not define what
> anonymous means in an EPR in our specs other than ReplyTo/FaultTo and
> leave this definition to the WSRX spec or other specs as appropriate
>
> dhull: yes, we define semantics for meaning of anonymous for
> ReplyTo/FaultTo, need to provide hooks to allow other specs to define
> ... establish terminology for others to use
>
> <GlenD> +1 to Dave's CR15 analysis
>
> Umit: getting more confused as to what problem dhull thins we are
> solving. IN terms of WSRX, what does anonymous mean in a non
> wsa-defined EPR. Can someone else define it to have the same meaning
> as a ReplyTo - the underlying response channel
>
> dhull: So lets give a name to a HTTP response in SOAP11 and the
> response message in SOAP12 and factor out the defintion
>
> Unit: We were pointing to the definition provided and the back
> channel. Your problem is the definition of channel, not what the
> resolution says which talks about EPRs
>
> <Zakim> anish, you wanted to say that david's suggested resolution is
> ok, but that this requires the WSRX to change their spec. If we can do
> ASAP, that would be good.
>
> <dhull> how does WS-RX refer to anonymous?
>
> Anish: define anonymous EPRs for everything so WSRX does not have to
> define it, dhull wants to be more specific in wsa and make other specs
> define it specifically.
> ... Want this fixed soon. Fast WSRX scehdule. Upcoming interop
>
> Umit: Why are we reopening the issue?
>
> Bob: Original resolution text to CR4, as pasted was agreed. What has
> changed to make that text to be unacceptable.
>
> dhull: Not well enough defined. Refers to 'such a channel' Since CR15
> we don't talk about channels, now talk about messages
>
> Bob: How do me generate minimal delta to CR4 to make it work
>
> dhull: how does WSRX refer to anonymous address?
>
> Umit: It doesn't. Leaves that to ws-addressing
> ... CR4 paragraph defines meaning of anonymous which is used by WSRX
>
> dhull: CR15 paragraph didn't mean anything, now narrowed to mean use
> response message when used as response endpoint and using response
> message when used as destination
>
s/CR15/CR4/. The whole reason for CR15 is that the CR4 paragraph didn't
make sense.
> Anish: 2 possible ways to make progress. Take resolution to CR4, make
> changes to align with CR15 (split wrt SOAP11/12)
>
> <TRutt> a WS-RX ack can occur at any time, and has the entire history
> of the sequence in it whenever sent. so there is no problem of stating
> "will be returned on some underlying http response"
>
> Anish: or take dhulls approach and define all anonymous EPRs and make
> WSRX define what anonymous AcksTo means using specific terminology
>
BTW, I don't think that was my approach, but Anish may well have said that.
> <dhull> right now, anon means "response to this request" or "this
> response"
>
> Umit: Do we have concrete understanding of the terminology as WSRX
> group think this issue is complete
>
> dhull: Do we have text saying what Anonymous means in an EPR in
> general? Yes.
>
Not sure what the context of that was. My main point was that we
/don't/ really define anonymous outside the core examples of [reply
endpoint], [fault endpoint] and [destination], and then only in a
limited context.
> <uyalcina> It does not help RX
>
> Anish: AcksTo set in different MEP. Set for sequence
>
> dhull: definitely not what addressing defines today
>
> <gdaniels> +q
>
> Tom: Never took anonymous to mean response to this message
> ... Up to ws-rx to clarify in their binding
>
> dhull: thinks its dangerous to rely on a ws-addressing ambiguity
> ... When I send an anonymous FaultTo I mean to send the fault on the
> response message of this message exchange, not some later one
>
> <uyalcina> It appears that David Hull does NOT agree with the
> resolution of CR4
>
> <dhull> dhull states clearly that the putative resolution to CR4
> didn't actually resolve CR4. Resolution of CR 15 is clearly "new
> information"
>
> glen: +1 to what dhull is saying. need clarification to state that
> response is part of the same MEP
>
> <dhull> David Hull is mostly OK with the stated resolution: "The
> paragraph in question should be extended to allow other EPRs to use
> the same semantics defined for the anonymous address." But you only
> want to re-use part of the semantics
>
> glen: if ws-rx need different they should define it. They shouldn't be
> using anonymous to mean any future response, they should mint a new URI
>
> Bob: Resolution to CR4 was agreement with external organisation. From
> credibility standpoint can we go back to CR4 and see if we can craft
> it to fit CR15
>
> Anish: willing to do this but would like to see how the group feels
> about htis first
>
> <uyalcina> Isn't this defined by the semantics of ReplyTo?
>
> Anish: Not clear why glen wants requirement that response is part of
> same MEP.
>
> <uyalcina> +1 to Anish
>
> glen: Interoperability, needs to know whether to expect response as
> response message if anonymous used
>
> <gdaniels> What's so hard about minting a new URI which means "any
> response on this sequence"?
>
> <gdaniels> "sequence" is a WS-RX concept, and understanding the
> semantics of the proposed new URI in fact DEPENDS on understanding
> that there will be future requests (i.e. that a sequence exists)
>
> <anish> glen, thinking about your response ... it might make sense to
> define a new URI (in wsrx)
>
> WS-RX waiting on ws-addressing resolving this issue
>
> Tom: Never took anonymous to mean anonymous on this request.
>
> <gdaniels> I would MUCH rather use clearly and consistently defined
> URI, even if two different ones, than make the meaning of anonymous
> "morph" based on whether it's in <acksTo> or <replyTo>
>
> <gdaniels> ew ew ew
>
> <dhull>
> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0085
>
> <anish> my understanding was that 'anon' referred to the channel not
> the channel for THIS req-res. Although Glen's point is valid
>
> <anish> wrt interop
>
> Tom: WSRX could define their own thing for use in AcksTo. Don't have
> problem with tight semantics for ReplyTo. Talking about applying
> semantics to different epr
>
> dhull: reviews resolution to CR15
>
> Umit: Have problem with restricting semantics
> ... Acks to defined by WSRX, should not be limited by ws-addressing
>
> dhull: hearing different things
>
> Umit: WSRX defining semantics of AcksTo, not anonymous
>
> <gdaniels> anonymous == "schmoo"
>
> Umit: on't want WSRX to redefine semantics of anonymous
>
> <dhull> +1 glen
>
> mnot: thinks dangerous to have people trying to represent 2 wgs on one
> call
>
> <gdaniels> I can always define the semantics of <AcksTo> to
> reinterpret any "ftp:" URL as an "http:" URL too, but I wouldn't want
> to do that....
>
> mnot: straightforward approach to return to other group
> ... already sort of done. issue of hats
>
> <gdaniels> (i.e. changing the meaning of identifiers based on context
> is in general bad)
>
> Anish: meaning of anonymous have changed again.
>
> <umit> +1 to Anish
>
> Anish: stated to mean devices without a URI, changed to mean back
> channel, now to back channel to specific request-response
>
> <Zakim> anish, you wanted to say that the semantics of 'anon' is
> changing yet again.
>
> <pauld> wonders why we need to worry about WS-RX if we don't preclude
> their use-case
>
> <TRutt> when I read
> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0085
> i see it being restricted to a response epr
>
> glen: Some of use feel this clarificationis what we meant to do
>
> dhull: What about a UDP message with no back channel
>
> Anish: it mean the back channel, the channel simply doesn't exist
>
> dhull: CR18 now specifically states semantics is undefined elsewhere
>
> Tony: in WS-RX is the sequence always between the same to endpoints
> with the same addresses
>
> Anish: A sequence can span multiple WSDL MEPs and clients
>
> Tony: So this is not what anonymous means (as an ack could go down any
> HTTP response in the sequence)
>
> <umit> I agree with Tom, we have an ambiguity there.
>
> dhull: CR15 qualified to ReplyTo or FaultTo - does not restrict
> semantics of AcksTo
>
> <umit> I should add that response endpoint is only defined within WSDL
> binding, not as a general definition either.
>
> dhull: Anonymous means my binding knows what to do. You can use it
> where you know it will be useful but there is an implict 'danger'
> warning there
>
> <umit> i do not see an issue here. The response endpoint is defined
> within the context of WS-A, not for WS-RX. It does not need to
> encompass AcksTo.
>
> Katy: agrees with Umit and Anish. Don't want to start restricting use
> of anonymous. Go back to CR4, leaving open for use
>
> <umit> We do not have to throw out the definition of cr15
>
> Katy: some work for exact details, someone takes cr4 and cr15 and work
> out the details
>
> Tony: anonymous has different meaning in different EPRs e.g. anonymous
> To and anonymoys ReplyTo in same message has different meaning
>
> <anish> btw, the use of 'anon' in the URL is very unfortunate. The URL
> has nothing to do with being anonymous
>
> <umit> response endpoint is defined in WSDL binding only.
>
> Tom: CR15 talks about response endpoints whereas CR4 was all about
> anonymous in non response EPRs. Think this can be resolved
>
> <uyalcina> +1 ti Tom
>
> Katy: Key. CR15 was specific to response endpoints
>
> Umit: Response binding only defined in WSDL binding. Should be crisper.
> ... Don't think we need to change anything from CR4
>
> Bob: Need an owner for CR23
>
> <anish> proposal: define 'anon' only in the context of
> reply-to/fault-to (not responses) and ask WSRX to defined their own
> URI for acksTo
>
> Katy: WIll attempt to resolve the inconsistencies
>
> <dhull> Go, Katy!
>
> Bob: No meeting next Monday. The Next meeting will be enxt week on
> Thursday and Friday at the F2F. We will possibly have a group lunch on
> Friday.
>
>
> Summary of Action Items
>
> [End of minutes]
> ------------------------------------------------------------------------
> Minutes formatted by David Booth's scribe.perl
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
> version 1.127 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
> $Date: 2006/02/21 11:43:01 $
>
Received on Thursday, 23 February 2006 20:30:52 UTC