<bob> zakim P6 is illsley

<Dug> zkim, IBM is Dug

<bob> scribe: tony

<TonyR> scribe: tonyr

Minutes of the last meeting

No objections - minutes of the last meeting accepted

Action Items

<scribe> Chair: we need more participation in the testing activities

Tony to implement the changes in response to CR31 - pending

Coordination with WS-Policy Group

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

CR33

<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

<Dug> +q

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?

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

This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: tony
Found Scribe: tonyr
Inferring ScribeNick: TonyR
Scribes: tony, tonyr

WARNING: No "Present: ... " found!
Possibly Present: Anish Anish_Karmarkar Bob_Freund DaveH Dave_Hull Dug Gil Gilbert_Pilz IBM IPcaller JonM Jonathan Jonathan_Marsh MarcH Marc_Hadley Mark_Little P11 P13 P3 P6 Paco PaulKnight Paul_Downey Paul_Knight TRutt_ TomR Tom_Rutt Tony TonyR Yves bob chad david_Illsley dhull gpilz katy marc pauld plh prasad proposal vote yinleng
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 11 Sep 2006
Guessing minutes URL: http://www.w3.org/2006/09/11-ws-addr-minutes.html
People with action items: