Agenda Review

Agenda accepted

Approval of minutes

Minutes accepted as mailed

Bob: Goal to reach conclusion on CR33, which is blocking CR31, which is blocking ending CR.
... Been working this for a couple of months, we need to conclude.

Action Items:

2006-08-21: cr31 - Tony Rogers to implement CHANGE 1&2 to the table in preparation for CR-31 PENDING
... will be done later today

Coordination and New Issues

Bob: Policy is requesting a non-normative referenec to WS-Policy.

Proposal: "The wsaw:UsingAddressing element MAY also be used in other contexts (e.g., as a policy assertion in a policy framework <such as WS-Policy [REF]>)."

Philippe: Request didn't go to public list... link here:

<plh> http://lists.w3.org/Archives/Public/public-ws-policy/2006Sep/0133.html

Bob: Controversial?

Tony: That's what we were suggesting as well...

Bob: No objections heard to adding this as a new issue, closing it by accepting the proposal.

CR033

Bob: Proposal 4 was posted last week by Anish, but we didn't have time to go over it.

Anish: Background: we have the wsaw:Anonymous marker, restricting values of FaultTo and ReplyTo, which we've modified to accomodate "none".
... WS-RX came up with an anonymous template, with slightly different semantics. It says "the current backchannel that has the same uuid as the current makeconnection."
... This isn't composible with wsaw:Anonymous.
... We need instead to talk about addressable endpoints rather than equivalent to our anonymous URI.
... Some folks asked for something runtime verifiable.
... The wsaw:isAnon flag in the message allows the service to verify that the non-Anon URI still should go on the backchannel.

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Sep/0028.html

Anish: Proposal here:
... Under "required" and "prohibited", the address has to be anon, none, or marked isAnon="true".
... Other specs could use this to define variants of anon or none.

David: In allowing none with anon, how did we deal with HTTP response?
... HTTP users will no be able to handle none.
... To the issue, the changes are interesting, signalling anonymity by something other than through a URI.
... Our core is extensible.
... Seems to obviate the need for the anon URI.,
... Have we thought through how the two work together, and how disruptive it is to what we have,

Anish: I think it's fairly limited. If this is marked in the WSDL, when you send a request, your FaultTo or ReplyTo can be any URI.
... If the client doesn't understand it, it simply won't put it in...

DaveO: What about putting it in core?
... saw Jonathan's note, agreed putting wsdl-markers into runtime stuff seems suspect.
... sent recent mail about putting it into the core (straw man). I'll make the argument it's not an incompatible change.
... We could put this in the Core namespace, and look at sending/receiving behaviors.
... We can see how forward/backward compatible it is.
... I squinted and think it might be a compatible change.
... If someone comes along and says it's a non-compatible change to the core, then it's hard to want to do as an extension.

<dhull> +1 in that the document doesn't matter

DaveO: In a sense this is adding a kind of typing behavior. We only provide a URI there, but we don't have a model for filling in your own values.
... Adding run-time typing might be an important change to do.

Jonathan: Marker might mean: ignore any validation you might do based on wsaw:Anonymous="required".

Anish: no, that means in the ReplyTo and FaultTo must either be wsa anonymous, none, or any other URI.

Jonathan: what's the difference?

<dorchard> Jonathan's point about "ignoring validation" is somewhat true, the marker does say "ignore the value".

Anish: I don't ignore it, I include the recognition of wsaw:isAnon.

<dorchard> Jonathan: There is no restriction on the value if the anon attrib is set.

<dorchard> Jonathan: When WS-A processor sees this, then it ignores the value, therefore it's core

<dorchard> jonathan: there are 2 different ways of looking at this

<dhull> so if the server sees isanon=true, then it basically pretends the [address] was anon?

Jonathan: Thinks there are two ways to look at this proposal.

<dorchard> jonathan: 1 way is that the wsdl is overridden, the other is overridiing core validation.

Paco: Is the intent that when you've got the flag, you can put any URI, or one that represents the backchannel?

Anish: As far as this marker goes, and as far as WSDL validation goes, then it follows the rules for the marker. You still need to process the special URI.

Paco: What if I give you an addressable URI with wsaw:isAnon="true"?

Anish: wsaw:Anonymous="required" means the response will always be on the backchannel.
... The specific URI in the EPR may have a specific meaning.

Paco: That meaning has to be compatible with the backchannel behavior?
... My question is about the backward compatibility issue:
... A client sends this marker to an old endpoint. Maybe the old endpoint doesn't understand the marker, it will choke because it doesn't understand the URI.
... But the WS-A processor will still choke.

DaveO: If WS-A processing is done first, it will choke. A layer before addressing might be able to handle it.

Paco: Suppose you have WS-A deployed, and we have RM deployed (assume somebody uses special backchannel). Now we publish this spec with the new flag, everyone crashes

(not sure I got that whole thing).

DaveO: Not backward compatible?

Paco: Not convinced it won't break existing endpoints.
... A client sends to a previously deployed endpoint. The endpoint breaks.

Gil: You're presuming that you can already use the WS-RM URI. But that's why we have this issue in the first place.

Paco: Concerned about pushing something to the runtime something we should do in the WSDL.
... I think we're too tight in assuming who will manage connections.

Anish: Seem to be pointing to the previous proposal.

Paco: Yes, sorry to go back there. We should have a better marker than a runtime artifact.

DaveO: Do you see any way we can support WS-RM's anonymous with wsaw:Anonymous?
... Any change to RM that isn't also incompatible with WS-Addressing?

Paco: You put it well - we're assuming to much about how much validation we do.

<anish> btw, paco, i would be ok with the previous proposal (or some version of it)

DaveO: Even changing the marker is not compatible.

Paco: Marker isn't done yet. We can change that.
... Sympathetic to the problem, but don't like this solution for the backward compatibility reasons.

Tony: Jonathan recorded Anish as saying that anonymous=required means anon, none, or any other uri, but should say any other uri with anon=true.
... Thinks Jonathan misminuted it.

Jonathan: Trying to tease out what "any other uri" means.

<GlenD> Tony was exactly right - when isAnon="true" that means "do NOT interpret this URI in the naive way (by just trying to send to it) - something special is going on"

Tony: You need something to process that special URI.

DaveH: Only difference between an EPR with an addressable value, and the same EPR with isAnon="true" is...

scratch above line.

DaveH: What's the difference to an anon-like address and an anon-like address marked as isAnon?

Tony: Should be no difference on the wire.

DaveH: We're just spelling anonymous differently.

Anish: We want to see WS-A and WS-RM composable. We aren't right now.
... I don't want to make it hard to turn on RM on an endpoint that only operates on the backchannel - without removing things from the WSDL.
... Several ways to solve this problem.
... We can ask WS-RM to redesign, which they already rejected.
... They sent one proposal to loosen the tightness between the marker and WS-A anon.
... I wrote up the isAnon marker proposal.
... I don't want to see that these two spescs aren't compatible. Worst solution possible.
... Second edition of Core, kicking back to WS-RM, etc. anything is better.

Gil: Wanted to answer DaveH, what's the difference when you add isAnon=true. Trying to communicate it one more time.
... Imagine you have a service that needs to be reliable. Need to retry responses when it determines it must.
... Now imagine Alice and Bob connecting to the service. Neither supports a listener.
... From the service's perspective, if it needs to resend a response back to Alice, it can't disambiguate between Alice and Bob.
... Both are addressed using the anonymous URI. It's got no information to correlate the replies.
... We've split out the fact of anon meaning use the back channel, leaving the uuid to disambiguate Alice and Bob.

DaveH: Gets that, talked about sending a cookie along.

Gil: Alice's wire and Bob's wire are different wires.

DaveH: You can't disambiguate that from the request.

Gil: Might need to create a new sequence, so you need to know who it came from.

DaveH: Can't use wsa:From?

Gil: At risk?

DaveH: Might be a good use for it.

Paco: With the isAnon marker, when I use the wsaw:Anonymous="required", that means the service trusts you to send a URI that encodes "anonymoous".
... Key point is that when you use the flag, you trust the client.

Tony: That's how I understand it.

Paco: You either send the real thing, or we trust you. We give up validation.
... if this is fundamentally changing the meaning of the marker. Why don't we make the marker informational: "I always send the response on the backchannel."

Anish: I'm fine with proposal 1 which is about asserting what the service can and cannot do.
... If the service says it can't do callbacks, it will send a fault.
... The complaint was the requirement is too fuzzy. I think that's OK.

Paco: Looks like when we put in this marker, and suspend validation.

Jonathan: In the absence of WSDL, does isAnon="true" change any behavior?

Tony: Yes, the response will come on the backchannel.

Anish: Can't say anything about what the behavior might be without WSDL.

<pauld> can't help thinking this belongs in core

<pauld> and that ship has sailed, for 1.0 anyway

<pauld> chad, question: options for cr33, again

<pauld> chad, option 0: Status Quo

<dhull> chad, option 1: Status quo, but clarify that "optional" makes no statement about what other addresses will work

<dhull> chad, option 2: Remove wsaw:anonymous and use Policy

Anish: Doesn't change behavior. The client is asserting it's anonymous.

<TonyR> chad option 9: misunderstand the proposal

<TonyR> chad, list options

http://www.w3.org/2002/ws/addr/cr-issues/#cr33

<TonyR> chad option 4: provide a marker to let a URI slide past the wsaw:Anonymous validation (Anish's proposal of today)

<TonyR> chad option 5: provide a marker to indicate that a URI requires a response on the backchannel

<pauld> chad, options?

<TonyR> chad option 3: Remove wsaw:anonymous and use policy (Katy's proposal)

option2: <wsaw:NewConnection> proposal

chad, option 2: <wsaw:NewConnection> proposal

DaveO: If I make up a new URI that means "don't use the backchannel", and I mark it as isAnon="true"
... that means that if someone has wsaw:Anonymous="required", I will process it.

Anish: Yes, but the service will still need to process that URI, if it understands it.

DaveO: I'm just going to inject this in there so that WS-A isn't going to fault either.

Anish: Paradox.

DaveO: Two levels of validation. WSDL-based, WS-A. We'll hope these aren't incompatible.
... Thought the proposal was a bit more strongly-typed. Guess not.

DaveH: From what I could tell, some is based on the misconception that wsaw:Anonymous="optional" means any URI will work. It doesn't, just that you can put anon URI there.

DaveH: Might want to emphasize that point in the text.
... which could be composed with Option 0 - status quo.

Option 0.1 Status quo, but clarify that "optional" makes no statement about what other addresses will work

Option 2: Change MUST to SHOULD

chad, Option 2: Change MUST to SHOULD

chad, Option 0.1 Status quo, but clarify that "optional" makes no statement about what other addresses will work

chad, Option 0: Status quo, but (possibly) clarify that "optional" makes no statement about what other addresses will work

Gil: Dug preferred Option 1 so each specification can maintain lists of URIs with anonymous semantics.
... right?

Bob: Loosen MUST to SHOULD so that you could rationalize the conflict.

Gil: Core already allows other URIs with anonymous semantics, right>?

Bob: right.

chad, Option 1: Change MUST to SHOULD

chad, option 2: <wsaw:NewConnection> proposal

<TonyR> chad option 1: change MUST to SHOULD (allows for other specs to define anon URIs)

chad, options?

Anish: Server needs to understand the URI in the address. If the server doesn't it will barf or make assumptions.
... Personally I like (2)...
... Regardless of whether isAnon is present or not, there is a URI which, if specified ala WS-RM, if the service doesn't understand that URI and know what to do, it will fault or do something strange.
... The service still has to understand what that URI means.
... I like (2) because it still validates, just says the service can/can't/must use backchannels.

<Zakim> dorchard, you wanted to ask about Paco's "kind of proposal"

DaveO: Were you talking about option 1 earlier?

Paco: Thinks 1 is closer.
... Thinks 2 is closer.

<Zakim> marc, you wanted to ask about option 3

Marc: Option 3, does this mean?

DaveO: Duck and run.

Jonathan: Indicates frustration with the baked-ness of wsaw:Anonymous, perhaps we shouldn't be RECOMMENDING this yet.
... Policy is a distraction.

DaveH: Idea is that policy might be a more composable framework for solving these kinds of problems better.

<anish> i would like to speak against proposal 3 -- without that, there is no way to specify "async" request response, like what rosettanet wants

<anish> that ==> wsaw:Anonymous

DaveH: Seems like a serious alternative to coming up with a special-purpose hard-wired WSDL marker.

<TonyR> chad, list options

DaveO: Does 2 solve RM's problem?

Anish: I think so.

<GlenD> Gotta run, folks. I'm going to abstain on this one, assuming we vote in the next 30 min.

Anish: It makes assertions about whether the backchannel can be used.
... or must

Gil: specifically lists the URIs that indicate the backchannel.

Anish: Just shows examples of URIs that indicate the backchannel...

<anish> vote: 2, 4, 5, 1

vote: 3,0

<gpilz> vote 2, 5, 4, 1

<David_Illsley> vote 3,2,1

<pauld> vote: 3, 0

<Paco> vote: 3, 2, 1

<gpilz> vote: 2, 5, 4, 1

<marc> vote: 0, 4

<dhull> vote: 0, 3, 5, 4

<TonyR> vote 5, 3, 0, 9, 4, 1

<PaulKnight> vote 3,2,0

<David_Illsley> vote: 3,2,1

chad, votes?

<plh> vote 1, 0, 3, 2

<PaulKnight> vote: 3, 2, 0

chad, votes?

<plh> vote: 1, 0, 3, 2

<TonyR> vote: 0, 5, 3, 9, 4, 1

chad, votes?

<pauld> chad, count

<chad> Question: options for cr33, again

<chad> Option 0: Status quo, but (possibly) clarify that "optional" makes no statement about what other addresses will work (3)

<chad> Option 1: change MUST to SHOULD (allows for other specs to define anon URIs) (1)

<chad> Option 2: <wsaw:NewConnection> proposal (2)

<chad> Option 3: Remove wsaw:anonymous and use policy (Katy's proposal) (5)

<chad> Option 4: provide a marker to let a URI slide past the wsaw:Anonymous validation (Anish's proposal of today) (0)

<chad> Option 5: provide a marker to indicate that a URI requires a response on the backchannel (0)

<chad> Option 9: misunderstand the proposal (0)

<chad> 11 voters: anish (2,4,5,1),David_Illsley (3,2,1),dhull (0,3,5,4),gpilz (2,5,4,1),Jonathan (3,0),marc (0,4),Paco (3,2,1),pauld (3,0),PaulKnight (3,2,0),plh (1,0,3,2),TonyR (0,5,3,9,4,1)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: First elimination round.

<chad> Eliminating candidadates without any votes.

<chad> Eliminating candidate 4.

<chad> Eliminating candidate 5.

<chad> Eliminating candidate 9.

<chad> Round 3: Eliminating candidate 1.

<chad> Round 4: Eliminating candidate 2.

<chad> Round 5: Eliminating candidate 0.

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - Remove wsaw:anonymous and use policy (Katy's proposal)

Bob: 0 and 3 are the most popular options.

DaveO: Might want to do a runoff between 3, 0, 2

<pauld> chad, drop option 9

<chad> dropped option 9

<pauld> chad, drop option 4

<chad> dropped option 4

<pauld> chad, drop option 1

<chad> dropped option 1

<anish> chad, list options

<pauld> chad, drop option 5

<chad> dropped option 5

<pauld> chad, count

<chad> Question: options for cr33, again

<chad> Option 0: Status quo, but (possibly) clarify that "optional" makes no statement about what other addresses will work (4)

<chad> Option 2: <wsaw:NewConnection> proposal (2)

<chad> Option 3: Remove wsaw:anonymous and use policy (Katy's proposal) (5)

<chad> 11 voters: anish (2),David_Illsley (3,2),dhull (0,3),gpilz (2),Jonathan (3,0),marc (0),Paco (3,2),pauld (3,0),PaulKnight (3,2,0),plh (0,3,2),TonyR (0,3)

<TonyR> vote: 0,3,2

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Eliminating candidate 2.

<chad> Round 3: Eliminating candidate 0.

<dorchard> vote: 2

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - Remove wsaw:anonymous and use policy (Katy's proposal)

vote: 3,0

<anish> vote: 2, 0

<David_Illsley> vote: 3

<dorchard> vote: 2, 0

<PaulKnight> vote: 3, 0

<pauld> vote: 3,0

<dhull> vote: 0, 3

<gpilz> vote: 2

<uyalcina> vote:0

<marc> vote: 0

<Paco> vote: 3

<jeffm> vote: 2,0

<plh> vote: 3,0,2

<pauld> chad, votes?

<uyalcina> vote:0,2

<pauld> chad, count

<chad> Question: options for cr33, again

<chad> Option 0: Status quo, but (possibly) clarify that "optional" makes no statement about what other addresses will work (4)

<chad> Option 2: <wsaw:NewConnection> proposal (4)

<chad> Option 3: Remove wsaw:anonymous and use policy (Katy's proposal) (6)

<chad> 14 voters: anish (2,0),David_Illsley (3),dhull (0,3),dorchard (2,0),gpilz (2),jeffm (2,0),Jonathan (3,0),marc (0),Paco (3),pauld (3,0),PaulKnight (3,0),plh (3,0,2),TonyR (0,3,2),uyalcina (0,2)

<chad> Round 1: Count of first place rankings.

<chad> Round 2: Tie when choosing candidate to eliminate.

<chad> Tie at round 1 between 0, 2.

<chad> Tie broken randomly.

<chad> Eliminating candidate 0.

<chad> Candidate 3 is elected.

<chad> Winner is option 3 - Remove wsaw:anonymous and use policy (Katy's proposal)

Option 3: 6 BT, CA, IBM, MS, Nortel, Tibco

Option 2: 2 BEA, Oracle

Option 0: 1 Sun

Anish: Option 0 doesn't solve the RM issue, but doesn't throw out the baby with the bathwater.
... Taking away wsaw:Anonymous after all the work we did loses the really important use case I discussed earlier.

<marc> i think Anish said that option 3 throws out the baby with the bathwater

<dorchard> ah

Anish: Saying a service needs to provide a callback channel.

Paco: Don't like 0, because we now have to choose between WS-A and RM.

Anish: Provides feedback to the WS-RM WG that they need to rethink.

<anish> yes, i meant option 3 throws the baby out with the bathwater, not option 0

Bob: Option 3 is a significant change, in the expectation of what information is carried in the WSDL. Option 0 continues to keep pressure on RM to figure out an alternative way to get the job done.

Bob: Objections with the clear winner (3). We'll see if option 0 is something people can live with.

Marc: I'd like to point out that we already say we can use Anonoymous in policy.

Jonathan: wsaw:UsingAddressing can be used in policy.

Paco: Bad way to do anonymous.

DaveO: If we're saying wsaw:Anonymous doesn't compose with policy, we should go down that path.

Bob: Formal objections against Option 3?

DaveO: Yes

Anish: Yes

DaveH: But you might be OK if it were replaced with a policy marker instead.

DaveO: Yes, but fixing it and removing it are different.

Jonathan: Can live with Option 0 if we open a new issue about redesigning wsaw:Anonymous as policy assertions.

Paco: Still has some problems with dealing with non-WS-A "special" URIs.
... Just recasting it as policy doesn't fully solve the problem.

Anish: Might be easier as a policy.

DaveO: Paco, you were pushing for 3 in preference for 2?

<anish> jonathan had sometime back suggested that instead of one wsaw:Anonymous marker we should have 3 different markers

<anish> which help from a policy POV

Paco: 2 will probably tell us we can solve RM's problem. We can live waiting until we solve this problem better, but first cast as a policy assertion, then with the "special" URI problem.

DaveO: We want something like this. Can you live with something like what RM has, cast it as a policy, and go from there?

Jonathan: Worried about trying to fix the "RM problem" as we cast into policy assertions. Still not sure we can't satisfy RM by tweaks there.

DaveO: Don't want to preclude tweaking to accomodate RM.

Paco: Not just an RM problem.

Jonathan: Postponing the debate on whether we change or RM does.

Bob: Put 33 on a backburner while we explore recasting as a policy assertion.

Jonathan: What do we tell RM?

Bob: Any objections to leave 33 open while we entertain a new proposal working the policy assertion.

none

Bob: Any takers to craft the proposal?

Anish & Paco volunteer.

adjourn