07:54:01 RRSAgent has joined #ws-addr 07:54:01 logging to http://www.w3.org/2006/03/02-ws-addr-irc 07:54:15 zakim, this is ws-address 07:54:15 sorry, TonyR, I do not see a conference named 'ws-address' in progress or scheduled at this time 07:54:21 zakim, list conf 07:54:21 I don't understand 'list conf', TonyR 07:54:29 zakim, list conferences 07:54:29 I see no active conferences 07:54:31 scheduled at this time are WAI_PFWG(F2F-TP)2:30AM, WS_AddrWG(TP)3:00AM, XML_XMLCore(TP)3:00AM 07:54:47 zakim, this is ws_addrwg 07:54:47 TonyR, I see WS_AddrWG(TP)3:00AM in the schedule but not yet started. Perhaps you mean "this will be ws_addrwg". 07:54:48 zakim, this will be ws_addrwg 07:54:49 ok, bob; I see WS_AddrWG(TP)3:00AM scheduled to start in 6 minutes 07:55:53 Meeting: WS-Addressing WG Face to Face meeting 07:56:31 Chair: Bob Freund 07:59:49 WS_AddrWG(TP)3:00AM has now started 07:59:56 +??P0 08:04:02 hugo has joined #ws-addr 08:04:29 Zakim, call IlesB 08:04:29 I am sorry, hugo; I do not know a number for IlesB 08:06:07 Nilo has joined #ws-addr 08:07:10 Zakim, call TP_Iles_B 08:07:10 ok, hugo; the call is being made 08:07:12 +TP_Iles_B 08:07:41 who is on the phone? 08:07:49 GlenD has joined #ws-addr 08:08:56 scribe:Nilo 08:10:03 Katy has joined #ws-addr 08:10:13 dhull has joined #ws-addr 08:10:50 zakim, who is on the phone? 08:10:50 On the phone I see ??P0, TP_Iles_B 08:11:23 zakim, ??p0 is MarkLittle 08:11:23 +MarkLittle; got it 08:12:41 uyalcina has joined #ws-addr 08:13:12 http://www.w3.org/2002/ws/addr/testsuite/report/ 08:13:31 agenda approved, with test status update included 08:14:35 Feb 20 minutes approval postponed to tomorrow 08:16:17 +??P1 08:16:46 test results from Jonathan: 5 implementations tested, results shown, basically a sea of green 08:17:42 a few optional features have no implementations; so they are at risk 08:19:45 zakim, who is on the phone? 08:19:45 On the phone I see MarkLittle, TP_Iles_B, ??P1 08:20:53 Bob would like to get PR text completed today and wants everyoe to work towards that 08:21:21 jeffm has joined #ws-addr 08:22:24 AI review - all AIs completed 08:23:09 yinleng has joined #ws-addr 08:23:40 Umit concerned about lack of WSDL implementations affecting the WSDL binding 08:24:54 Bob says that we have a choice re WSDL binding - choice of 1) making doc a Note or 2) changing the number of implementations needed to progress it 08:25:20 -??P1 08:25:22 TRutt has joined #ws-addr 08:25:54 +??P1 08:26:07 Topic: proposed issue 1 08:26:12 zakim, ??P1 is me 08:26:12 +yinleng; got it 08:26:14 http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0000 08:28:17 anish has joined #ws-addr 08:28:24 DH thinks this is a potentially editorial change and can be done after we have agreed to the other changes to this text 08:29:04 Umit: how is SOAP1.1 text affected 08:29:45 http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Feb/0002 08:30:06 Topic: proposed issue 2 (see link above) 08:31:06 Allen has joined #ws-addr 08:34:02 jonathan: two action values - one for addressing-specific faults, another for application-level ones 08:34:54 Hugo: concern with the term "generic SOAP faults" 08:34:55 dorchard has joined #ws-addr 08:35:40 general consensus re the action value for the addressing-specific faults 08:36:49 with one addition: add a reference to the section on the Faults section 08:37:25 The [action] property below designates WS-Addressing fault messages: 08:37:25 08:37:25 http://www.w3.org/2005/08/addressing/fault 08:37:25 08:37:25 *This action SHOULD NOT be used as an action value in messages other 08:37:26 than those carrying WS-Addressing faults.* 08:37:28 08:37:28 section 6.4 08:37:30 SOAP modules and extensions SHOULD define custom [action] values for 08:37:32 the 08:37:34 faults they describe but MAY designate use of the following [action] 08:37:36 value 08:37:38 instead: 08:38:35 FabGandon has joined #ws-addr 08:38:43 Katy: change "generic faults" to "such as..." 08:38:45 marc has joined #ws-addr 08:39:18 DaveO: call them "SOAP defined faults" instead of "generic SOAP faults" 08:39:31 SOAP defined SOAP faults 08:40:11 The above [action] value SHOULD be used for SOAP defined faults 08:40:11 including 08:40:11 version mismatch, must understand, and data encoding unknown. *This 08:40:11 action SHOULD NOT be used as an action value in messages other than 08:40:11 those carrying SOAP defined faults or those of SOAP modules and 08:40:12 extensions.* 08:40:14 08:40:16 I use SHOULD because this is a hard thing to test, seems like the 08:40:18 appropriate level of guidance, and doesn't force a breaking change in 08:40:20 implementations at this point. 08:40:22 08:40:24 Original thread that sparked this follows... 08:41:45 The above [action] value SHOULD be used for SOAP defined SOAP faults 08:41:45 including 08:41:45 version mismatch, must understand, and data encoding unknown. *This 08:41:45 action SHOULD NOT be used as an action value in messages other than 08:41:45 those carrying SOAP defined SOAP faults or those of SOAP modules and 08:41:46 extensions.* 08:41:48 08:41:50 I use SHOULD because this is a hard thing to test, seems like the 08:41:52 appropriate level of guidance, and doesn't force a breaking change in 08:41:54 implementations at this point. 08:41:56 08:41:58 Original thread that sparked this follows... 08:42:29 chad has joined #ws-addr 08:43:57 Marc: seems a bit contradictory 08:44:45 Glen: may want to have infrastructure choose the appropriate action value 08:46:27 consenusus building around closing the second part with no action 08:46:54 Umit: what's the reason for the second part 08:47:28 Jonathan: it would be nice to know if it was ageneric SOAP fault as opposed to a app level fault. 08:47:43 Glen: it almost seems like over-riding SOAP fault codes 08:49:28 Anish: still need to change the para between the two action value. 08:49:53 s/SOAP modules and extensions/SOAP modules, extensions and applications/ 08:50:06 in section 6 08:51:33 This is marked as CR24 08:51:47 Resolved CR24 08:51:51 as above 08:53:12 Topic: One paragraph out-optional-in note 08:54:14 The above [action] value SHOULD be used for SOAP defined faults 08:54:14 including 08:54:14 version mismatch, must understand, and data encoding unknown. *This 08:54:14 action SHOULD NOT be used as an action value in messages other than 08:54:14 those carrying SOAP defined faults or those of SOAP modules and 08:54:15 extensions.* 08:54:17 08:54:19 I use SHOULD because this is a hard thing to test, seems like the 08:54:21 appropriate level of guidance, and doesn't force a breaking change in 08:54:23 implementations at this point. 08:54:25 08:54:27 Original thread that sparked this follows... 08:54:39 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/att-0072/soap11reqoptresphttpbinding.html 08:57:00 This SOAP 1.1 request optional response HTTP binding, in conjunction with the SOAP 1.1 binding, can be used for sending request messages with an optional SOAP response. This binding augments the SOAP 1.1 binding by allowing that the HTTP [RFC 2616] response MAY have a 202 status code and the response body MAY be empty. Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal". As such, any content in the respon 08:58:13 This SOAP 1.1 request optional response HTTP binding, in conjunction 08:58:13 with the SOAP 1.1 binding, can be used for sending request messages with 08:58:13 an optional SOAP response. This binding augments the SOAP 1.1 binding 08:58:13 by allowing that the HTTP [RFC 2616] response MAY have a 202 status code 08:58:13 and the response body MAY be empty. Note that the HTTP [RFC 2616] 08:58:14 specification states "the 202 response is intentionally non-committal". 08:58:16 As such, any content in the response body, including a SOAP body, MAY or 08:58:18 MAY not be an expected SOAP response. 08:58:57 This SOAP 1.1 request optional response HTTP binding, in conjunction with the SOAP 1.1 binding, can be used for sending request messages with an optional SOAP response. This binding augments the SOAP 1.1 binding by allowing that the HTTP [RFC 2616] response MAY have a 202 status code and the response body MAY be empty. Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal". 08:59:08 As such, any content in the response body, including a SOAP body, MAY or MAY not be an expected SOAP response. 08:59:46 This SOAP 1.1 request optional response HTTP binding, in conjunction with the SOAP 1.1 binding, can be used for sending request messages with an optional SOAP response. This binding augments the SOAP 1.1 binding by allowing that the HTTP [RFC 2616] response MAY have a 202 status code and the response body MAY be empty. Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal". As such, any content in the response 09:00:16 pauld has joined #ws-addr 09:00:59 chad, you don't understand, much :-( 09:01:43 Umit: can the last sentnce be reworded? 09:04:20 Anish: this is an op response, so you could also get back 202 with and without a SOAP env, as well as a 200 with a SOAP env 09:04:54 Bob: we need new text starting from "As such..." 09:05:02 At the risk of prolonging the discussion I note that SOAP 1.1 doesn't preclude a HTTP 202 without a SOAP entity body: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383529 09:05:49 Anish: propose striking snetnce starting "As such..." 09:06:55 s/snetnce/sentence 09:07:21 Jonathan: 09:07:30 how does this affect the test suite 09:07:57 Glen: the 202 is used in the test suite 09:08:35 Another slight wording mod of the last 2 sentence.. 09:08:36 Note that the HTTP [RFC 2616] specification states "the 202 response is intentionally non-committal" and so any content in the response body, including a SOAP Envelope, MAY not be an expected SOAP response. 09:10:24 Text above agreed 09:10:34 Issue resolved, and we will publish as a NOTE 09:11:04 Break until 10:45 09:16:08 -yinleng 09:35:53 Katy has joined #ws-addr 09:40:27 Katy has joined #ws-addr 09:40:34 -MarkLittle 09:41:33 TRutt has left #ws-addr 09:45:01 above resolution is to clean up and publish the note: 09:45:06 N.B. 09:45:22 Bob- talk to hugo about how to publish 09:46:09 resuming meeting again 09:46:23 topic: CR23 09:47:17 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Feb/0189.html 09:47:43 alternate proposal: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0005.html 09:47:51 TRutt has joined #ws-addr 09:48:33 marc has joined #ws-addr 09:50:56 q+ 09:51:51 ack ani 09:53:15 q+ 09:53:47 q+ 09:53:55 q+ 09:54:09 Anish: has an alternative proposal and suggests that this isuue be closed with no action 09:54:10 ack um 09:54:40 ack u 09:54:46 umit: it is WS_RX's choice to use our anon URI or mint their own 09:54:57 q+ 09:55:02 q+ 09:55:07 ack gl 09:55:12 Glen: agrees with Anish 09:56:00 ack k 09:56:00 Glen: we don't need to encourage WS-RX to use this URI in ways that may not be these semantics 09:56:59 Katy: the semantics is that it depends on the underlying SOAP transport binding 09:57:21 q+ 09:57:28 q+ 09:58:05 ack an 09:58:22 q+ to indicate that using a different URI is more comprehensible than looking up a namespace for an EPR header such as 09:58:31 Katy: It allows RX to go either way - use this URI as we define it or define their own URI for acksTo 09:59:07 I am very comfortable in reverting a request that came from RX and forcing a particular decision on them, 09:59:18 we should give them the choice 09:59:24 q+ 09:59:27 ack jon 09:59:29 s/comfortable/uncomfortable/ 09:59:30 Anish: not comfortable with making its meaning context sensitive 10:00:17 Jonathan: there is value in making this URI mean that it depends on the infrastructure 10:01:07 ack dh 10:01:21 Jonathan: in short, agreeing with Katy 10:02:01 q+ 10:02:08 ack tr 10:02:19 DH: if you are using anon, you need to understand the context it is to be used 10:02:53 q+ 10:03:09 ack gl 10:03:09 GlenD, you wanted to indicate that using a different URI is more comprehensible than looking up a namespace for an EPR header such as 10:03:28 q+ 10:03:33 q+ addressing RX minting their own URI 10:03:35 Tom: could go either way, but does not see why a spec can't define its own EPR's semantics 10:03:45 q+ to addressing RX minting their own URI 10:04:12 q? 10:04:53 Glen: in summary would prefer WS-RX to mint its own URI 10:04:56 ack dor 10:07:06 DOR provides an analogy to java abstract vs concrete classes 10:07:23 ack ani 10:08:48 q+ 10:09:06 q+ to point out that RX is not the only potential reuser of anon 10:09:34 q+ 10:09:42 ack uy 10:09:50 anish: we don't disallow use of anon in any other context. we simply define its use for reply/failtTo 10:10:27 Tom just made an interesting point - when you see a URI, you tend to want to deference it to see what it means... 10:10:39 umit: there is an abstract/concrete analogy. abstract is "any back channel" while concrete is specific back channels in specifc contexts 10:10:56 If it's RX's "sequenceBackchannel" URI, that's clearer than "W3C's no-real-meaning-anonymous URI" 10:11:00 dorchard has joined #ws-addr 10:11:03 q? 10:11:10 ack ka 10:11:10 q+ 10:11:34 q+ to follow my nose on wsa:anon vs wsrx:anon 10:12:25 q- 10:12:27 anish: the current text encourages you to use this URI in a different context 10:12:36 ack tony 10:12:36 TonyR, you wanted to addressing RX minting their own URI 10:12:53 Tony: RX should define their own URI because it has a different meaning 10:12:58 q- 10:13:00 uyalcina has joined #ws-addr 10:13:33 q+ Jonathan 10:13:42 q+ 10:13:45 ack dhu 10:13:45 dhull, you wanted to point out that RX is not the only potential reuser of anon 10:13:58 Please folks, WS-RX ASKED us to loosen up the definition of the URI for them. 10:14:03 This is why we are discussing this 10:14:25 the issue about implementations changing is a red herring, imho, it does not change the impl much. There are a whole lot of changes that are currently taking place in wsrx which are huge compared to this tiny 'if' stmt change 10:15:29 +1 to DH. 10:15:29 ack hu 10:15:32 DH: we should leave the door open for future SOAP bindings which have back channels; so we should provide guidance for what anon might mean for them 10:16:31 ack dor 10:16:31 dorchard, you wanted to follow my nose on wsa:anon vs wsrx:anon 10:16:33 q+ to call the question (let's vote!) 10:16:33 Hugo: support Anish's proposal 10:17:59 Additional text does not force rx to use anon URI - just states that, if it is used, the behaviour must be specified in RX context. 10:18:37 DO: in either case, the RX spec implementers will have to look at their spec to see how the anon value is used 10:19:31 q+ 10:19:48 ack jon 10:21:26 Jonathan: wants to allow anon to be used with AcksTo as used today 10:21:40 pingpong 10:21:45 pingping 10:21:56 ack tr 10:22:13 pingpang 10:23:15 q+ to ask is the core of Katy's proposal to call out the context dependent. 10:23:15 ack glen 10:23:16 GlenD, you wanted to call the question (let's vote!) 10:23:22 Tom: happier with Anish's proposal, but could edit Katy's proposal to meet concerns 10:23:53 pingaling 10:24:25 Is it almost the straw poll of "do you want anon re-used or not"? 10:25:08 pingkitten? 10:25:13 q? 10:25:14 pingkitten 10:25:18 Glen: want to get a sense of the group 10:25:50 Katy: RX implementations are using the anon URI 10:26:08 Marc/Anish: they are not using this CR anon URI 10:26:14 ack ani 10:26:28 has no sympathy for WS-RX, they're referencing a moving target 10:26:30 Anish: RX uses the old anon URI 10:27:27 Umit: the semantics of the old anon URI was "any back channel" which is what Katy's proposal is trying to capture 10:27:31 Umit - it doesn't matter that it's the SAME anonymous URI as addressing uses, though, does it? 10:27:42 If they need to change anyway, is it that big a deal? 10:27:49 it does matter RX. 10:27:54 They asked us to define it for them 10:28:05 s/matter/matter to/ 10:28:13 what implementations are using our freshly minted URI?! 10:28:13 I'm asking Umit the architect/developer, not Umit the politician. :) 10:28:28 i was the one who raised CR4 on behalf of WS-RX 10:29:15 poll to adopt katy's proposal 10:31:25 straw poll: for 6 against 7 10:32:42 q? 10:32:42 it was 6 to 8, actually 10:33:06 q+ 10:33:11 ack do 10:33:11 dorchard, you wanted to ask is the core of Katy's proposal to call out the context dependent. 10:33:40 q+ 10:34:01 q+ 10:34:03 Tom: the input WS-RX did not use "anon" 10:34:48 Bob: can we live with no action? 10:35:09 And, can we live with Katy's proposals? 10:35:13 Umit: I was given the AI by WS-RX TC to define the use of "anaon" 10:35:22 s/anaon/anon 10:35:25 pingy_thing 10:35:45 q+ to ask more people 10:36:52 BoB: I take charge of this AI and response to WS-RX 10:38:03 Bob: What needs to change in the proposal to make it acceptable? 10:38:19 q+ 10:38:59 q+ 10:39:04 q+ 10:39:09 DO: I thought we voted for the intent, not the exact text 10:39:34 q+ 10:39:44 ack gl 10:40:19 q- 10:41:54 q+ 10:42:05 ack dh 10:42:17 Glen: Minting URIs is easy and there does not seem to be a benefit to use the same URI with different meaning 10:43:15 DH: WS-RX found the "back channel"semantics of anon to be useful to reuse 10:45:07 ack do 10:45:07 dorchard, you wanted to ask more people 10:46:43 q+ 10:47:52 Vikas: For a non synchronous transport, you do not want somebody to specify what the back channel is 10:48:01 ack ani 10:49:58 Anish: does not achive the reuse objective. WS-RX sequence can make use of many differnt binding fora given sequence; so this text may not be able to describe the RX scenarios. 10:50:58 anish, this only doesn't work if there's a non-soap binding.. 10:51:04 ack hu 10:51:04 Bob: anon means "knows what to do" 10:51:18 dave, or another soap/http binding 10:51:40 ack jeff 10:51:44 Hugo: does not understand what this text will do 10:51:48 dave, or if you use soap 1.1 and smtp or another transport protocol 10:52:15 anish, if somebody else defines soap/http then they would have to do anon.. 10:52:50 right, and they would not be using our soap addressing binding, so any text we put it in there cannot be used by wsrx 10:52:54 jeff, aren't we defining extensible semantics though? That is the semantics are of re-use... 10:53:02 The URI's semantic is the same=back channel 10:53:15 Jeff: if you use a URI defined in a spec you are confined to its semantics. If anyone wants to use a differnt semantics, define a different URI. Problem if different specs continue to use anaon with different semantics 10:53:21 can we do a can-live-with poll 10:53:28 what we are debating is the semantics of the EPRs that use the URI 10:53:49 wakes up for what sounds like a versioning and extensibilty discussion 10:53:54 s/does not understand what this text will do/I do not understand why people care about this so much as it's not clear that any of the option will change anything; let's change find an option that everybody can live with and move on/ 10:54:34 ? 10:54:36 q? 10:54:37 q? 10:55:52 Bob: can anyone not live with closing with no action? 10:56:45 q? 10:56:48 Tom: I don't want to suggest reuse in the text, becasue if you do you have to put in all sorts of caveats. 10:56:51 ack tr 10:57:01 Tom: katy's text needs worsmithing. 10:57:10 ack jon 10:57:55 +1 To Jonathan 10:58:00 anonymous means "do the right thing" 10:58:11 ack ka 10:58:16 jonathan, do u think we need to say that or is it enuf for wsrx to say that? 10:58:22 q+ to point out that jonathan's point is valid, but that's not what the words SAY at the moment 10:58:38 i.e., with status quo we wsrx can do exactly what u are suggesting 10:59:00 s/we// 10:59:15 I think we've overconstrained anonymous already. 10:59:20 ack tony 10:59:20 TonyR, you wanted to point out that jonathan's point is valid, but that's not what the words SAY at the moment 10:59:21 how? 10:59:37 we in fact only say right now what it means in replyTo and faultTo 10:59:46 we don't say anything beyond that 11:00:06 Tony: At this point it does not say "knows what to do" 11:00:10 I assert that the anon is a special value and it means that a user will have to look at context, and the good part of Katy's proposal is to highlight that people need to describe their use.. 11:01:15 Additional text clarifies what is required by those who want to reuse anonymous - i.e. it must be defined when used outside ws-a context 11:01:24 q? 11:01:56 Anish: we do not say what anon means outside replyTo/FaultTo 11:02:30 Jonathan: we constriant what it means at the SOAP level and the HTTP level 11:02:48 s/constriant/constrain 11:03:15 Katy's text is simply "caveat emptor" .. I puzzle how to write test cases for it .. 11:03:16 Zakim, who's on the phone? 11:03:17 On the phone I see TP_Iles_B 11:03:28 Zakim, drop TP_Iles_B 11:03:28 TP_Iles_B is being disconnected 11:03:29 WS_AddrWG(TP)3:00AM has ended 11:03:30 Attendees were TP_Iles_B, MarkLittle, yinleng 11:05:00 section 5.1.2 says: 11:05:02 When "http://www.w3.org/2005/08/addressing/anonymous" is specified for the [reply endpoint] property and the message is the request part of a SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts], then any response MUST be the response part of the same SOAP request-response MEP [SOAP 1.2 Part 2: Adjuncts]. 11:05:42 Bob: Does the spec overly constrain the use of anon? 11:06:43 q? 11:06:47 q+ 11:06:57 Tony: heading of 5.1 needs to be changed. Add some text to say that this section defines the use of anon in the ctx of WSA. 11:07:01 q+ 11:07:07 q- 11:07:17 q+ to point out that CR18 resolution gets us almost there 11:07:23 Anish: apart from the section heading, text does not constrian you in any way. 11:08:56 Bob: over lunch, small group will work on new text 11:10:47 DH: pending c18 will also affect this text 11:11:14 bob: anish and katy will work on text over lunch, followed by formal vote 11:11:25 LUNCH BREAK 11:11:32 resume 1:15PM 12:16:15 TonyR has joined #ws-addr 12:18:27 Katy has joined #ws-addr 12:21:34 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Mar/0008.html 12:30:36 Scribe: Bob 12:31:47 Katy: explains the proposal prepared over lunch 12:34:30 The precise 12:34:30 meaning of this URI ** within the context of Addressing ** is defined by the binding of Addressing to a 12:34:30