See also: IRC log
No objections - minutes of the last meeting accepted
<scribe> Chair: we need more participation in the testing activities
Tony to implement the changes in response to CR31 - pending
MarcH: good if the Policy
Attachment spec described the merging / overriding of policy
attached to an EPR with policy embedded in an EPR
... there is some confusion on whether it overrides, but not
clear
<scribe> Chair: are the members of the group satisfied that it is up to the Policy WG to define what happens?
Paco: yes
MarcH: the spec isn't clear, but it's up to them
<pauld> it may or may not be their issue, but for sure it's not our issue :-)
<scribe> Chair: I will communicate to their WG that the ball is in their court - their problem
<scribe> Chair: potential effects on WS-Reliable Messaging and XMLP of CR33
<scribe> Chair: scheduling time on Wednesday (WS-CG) for dealing with this issue
<scribe> Chair: may need a joint meeting of WS-Addr, WS-Reliable Messaging, and other interested parties to address this issue
JonM: suggested an alternative proposal using RefParms
Dug: TAG frowns on that approach
<scribe> Chair: This is not related to the identity issue, which is where the TAG was concerned
<scribe> Chair: It indicates which type of response the server will generate?
Dug: no, it indicates the
identity of the endpoint
... it's not identifying the message, but rather the
endpoint
JonM: not convinced that it's identifying the endpoint - there's only one backchannel, so how we disambiguate them
<Dug> +1 Gil
Gil: the problem with trying to
use RefPs is (DaveO's opinion): one is supposed to echo the
RefPs to the client - the server is NOT supposed to "crack
open" the RefPs
... this is crossing the line between RefParams and
RefProperties (and we have removed RefProps from WS-Addr)
DaveH: the way we defined
Anonymous in WS-Addr carefully avoided any discussion of
channels and back-channels. We said that it's valid only in a
particular context. When Anon is used for a response endpoint,
then one puts the message in the Response part of a
Request-Response MEP.
... carefully avoiding discussion of backchannels, it's a
behavioural cue
... In the WS-RX context, we are still talking about using the
Response portions of future messages (and their MEPs). Only
context we have in this is the sequence id.
Paco: there doesn't seem to be a lot of convergence to this discussion. Chair's desire to resolve this in a joint meeting is a good idea
<Dug> +q
<scribe> Chair: in terms of alternative proposals: we have Jonathan's new one, and the one from last week
<pauld> and the Status Quo
Dug: if we could loosen up the wording relating to the anonymous URI, we could resolve it that way
<anish> i also think that it is identifying the endpoint not the sequence
<anish> tony, the wsrm uri is not a single uri but a template
MarcH: there seem to be two ideas as to what is being identified. Would like to understand why they think these are different
Dug: there needs to be some unique field in the message to identify which client (potentially among many clients) is "on-the-line" for receiving responses
JonM: the "small change" requested makes the coding for the wsaw:Anon assertion radically different - has a dramatic impact on the WS-Addressing implementation
<Dug> I have implemented it and coding it up isn't messy :-)
JonM: it requires making the WS-A implementation aware of WS-RX
Gil: there's an inherent contradiction. The RM protocol is inherently one-way. It allows the client to contact the server at arbitrary times to solicit responses.
<pauld> but presumably Dug, your implementation wasn't a WS-Addressing which didn't know or care about WS-RX, then had WS-RX layered upon it?
Gil: The server doesn't have that
option if the client cannot "listen" for responses. So how does
the server re-send responses if it thinks the client hasn't
received them?
... Does that clarify the rationale for this issue?
<gpilz> oops
Bob: can visualise multiple solutions to this problem. Thinking in terms of layered implementations, perhaps there's a layer under RM that handles the virtual proxying of these queued messages.
DaveH: if I understood Gil correctly, the idea is that the "magic cookie" tells the RM server who is contacting it and therefore is ready to receive a response. Leaning towards JonM's position
MarcH: Sounds like RM is overloading ReplyTo to mean where the reply should go, PLUS which reply to get (which queue of responses to get a response from)
Dug: No, that's not how it works.
<Dug> ok bob - I remember now :-) sorry
Anish: the RM group considered
four options for tackling this problem
... decided to go with the template approach for good
reasons
<Dug> dhull - wouldn't that be transport specific?
<dhull> How so? I send MakeConnection(anon, 12345). E.g., one child is anon, one is 12345. You could also use this with a non-anon URI. It's basically multiplexing behavior. (I'm not sure I yet grok why ref params don't work, but I'll take that on faith)
Bob: the queuing layer at the bottom of RM is the application receiving the content of the RefParam, and is therefore NOT a violation of the opaqueness criterion
<dhull> Hmm ... could I get one message for the connection on anon and one on non-anon? E.g., I happen to know who you are. I try pushing a message to you. Sometimes it works. Sometimes it doesn't, but you're also sending me messages. So if I see one of those I piggyback on it.
Dug: the impact on the code is minimal, because it just means that the code which interprets the URI changes to add a case for handling these kinds of URI
<Yves> Yves notes also than a 202 to return something other than information about the _processing_ of the request is invalid. Also sequence of req/resp should be taken cautiously, as a proxy might be in between and ruin assumptions
<Jonathan> soory, phone seems fritzy
Anish: people who are pushing back on the proposal, are they suggesting that RM define a RefParam at the MakeConnection level?
<Jonathan> A WSDL extension can say, "extend wsaw:Anonymous to include pseudo-anonymous."
<Jonathan> one way only
<Jonathan> one way only
<Jonathan> yes
<Jonathan> 2will redial
Dug: how do we define a new
marker in RM to provide the pseudo-anon capability?
... need ability to have both markers (WS-A anon and RM anon)
in a WSDL, to support both RM-aware and non-aware apps.
<Jonathan> please continue!
Anish: don't like the idea of having one marker override another - distasteful solution
Dug: if we can't extend the existing marker, can we have an extensibility point here?
Anish: it's more than that - it's a case of overriding the semantics of the existing marker
Katy: when we were discussing this, we decided to keep it simple. Not inclined to change it now
<scribe> Chair: are we ready for a straw poll on this?
bob:: choices: close with no action, accept Dug's proposal
<Dug> proposal: just tweak the wording but keep same name/semantics
<Dug> to talk about async
Anish: third option: find a compromise that makes everyone equally unhappy
Dug: fourth option: change wording to describing in terms of asynchonicity
<Katy> Tony: Yes - point was wsaw:Anonymous complicated enough for little extra benefit
<Katy> don't need extensibility points too
Dug: code already looks at the URI to send messages to, so the code changes are minimal
Tony: Not true - that code is not expected to change up to a different layer of code to select a different message to send
TomR: want the poll to allow incorporate the option of small changes to clarify matters
<Dug> Tony - the logic to get a msg may be hard or easy - I agree,but its not a big hit to the "current" WSA code - no comment on how big the new code is.
<Katy> <wsap:AddressableResponsesOnly/> and <wsap:NonAddressableResponsesOnly/>
Katy: if we are considering changing the wsaw:AnonymousRequired, perhaps we should allow the use of two flags: <wsap:AddressableResponsesOnly/> and <wsap:NonAddressableResponsesOnly/>
<Zakim> Jonathan, you wanted to dispell incomposability argument
Anish: was suggesting giving it more time to find a compromise
<scribe> Chair: do we think we should try to solve this; do we think this is not our purview; do we need to involve everyone else (XMLP / TAG / et al)?
<scribe> Chair: not seeing much progress today
<pauld> chad, options for issue-33
<pauld> chad, option 3: summit
<pauld> chad, option 2: status quo
<pauld> option 1: head-banging
<pauld> chad, question: options for ISSUE-33
vote: 3, 2, 1
<pauld> chad, option 1: head bangign
<dhull> vote: 2, 1, 3
vote: 3, 2, 1
<TRutt_> vote: 1
<anish> vote: 1, 3
<Jonathan> vote: 2, 3
<Katy> vote: 3
<Yves> vote: 3, 2, 1
<marc> vote 2, 3
<pauld> vote: 2
<marc> vote: 2, 3
<pauld> chad, option 1: head banging
<gpilz> vote: 1, 3
<prasad> vote: 2, 3
<pauld> chad, count
<chad> Question: options for ISSUE-33
<chad> Option 1: head banging (3)
<chad> Option 2: status quo (5)
<chad> Option 3: summit (3)
<chad> 11 voters: anish (1,3),dhull (2,1,3),gpilz (1,3),Jonathan (2,3),Katy (3),marc (2,3),pauld (2),prasad (2,3),TonyR (3,2,1),TRutt_ (1),Yves (3,2,1)
<chad> Round 1: Count of first place rankings.
<chad> Round 2: Tie when choosing candidate to eliminate.
<chad> Tie at round 1 between 1, 3.
<chad> Tie broken randomly.
<chad> Eliminating candidate 1.
<chad> Round 3: Tie when choosing candidate to eliminate.
<chad> Tie at round 2 between 2, 3.
<chad> Candidate 3 has the fewest votes at round 1.
<chad> Eliminating candidate 3.
<chad> Candidate 2 is elected.
<gpilz> me "strange little bots with obscure syntax are no basis for a system of government"
<chad> Winner is option 2 - status quo
<Dug> +1 to the 2nd part :-)
<scribe> Chair: not a clear position - close to balance between close with no action and continued head-banging
Tony: I'd like to see more detailed descriptions of approaches on the e-mail list
<scribe> Chair: will take this issue to WS-RM to assess their position