Web Services Addressing WG Teleconference

 

 

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

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

<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? No.

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