See also: IRC log
Agenda accepted
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.
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
Bob: Policy is requesting a non-normative reference 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...
Resolution: No objections heard to adding this as a new issue next in order and closing it by accepting the proposal.
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 accommodate "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, signaling
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 overriding 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 specs 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
"anonymous".
... 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
bath water.
... 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 bath water
<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 bath water, 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 Anonymous 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 accommodate RM.
Paco: Not just an RM problem.
Jonathan: Postponing the debate on whether we change or RM does.
Bob: Put 33 on a back burner 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