19:49:52 RRSAgent has joined #ws-addr 19:49:52 logging to http://www.w3.org/2006/10/23-ws-addr-irc 19:50:08 zakim, this will be ws_addrws 19:50:08 I do not see a conference matching that name scheduled near this time, bob 19:50:36 zakim, this will be ws_addrwg 19:50:36 ok, bob; I see WS_AddrWG()4:00PM scheduled to start in 10 minutes 19:51:00 Meeting: Web Services Addressing WG Teleconference 19:51:04 David_Illsley has joined #ws-addr 19:51:11 Chair: Bob Freund 19:52:17 TonyR has joined #ws-addr 19:53:14 Dug has joined #ws-addr 19:53:44 WS_AddrWG()4:00PM has now started 19:53:51 +Doug_Davis 19:55:46 +Bob_Freund 19:56:02 +??P4 19:56:22 zakim, ??p4 is me 19:56:22 +TonyR; got it 19:56:37 zakim, who is on the phone? 19:56:37 On the phone I see Doug_Davis, Bob_Freund, TonyR 19:56:41 + +44.196.286.aaaa 19:57:06 agenda: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0095.html 19:57:08 zakim, +44.196.286.aaa is me 19:57:08 +David_Illsley; got it 19:57:48 How do i tell zakim to list me as "Dug" instead of "Doug_Davis" ? 19:58:15 +??P6 19:58:25 zakim, Doug_Davis is Dug 19:58:25 +Dug; got it 19:58:28 cool - thanks! 19:58:38 pauld has joined #ws-addr 19:58:38 MrGoodner has joined #ws-addr 19:58:57 zakim, cool - thanks! 19:58:57 I don't understand 'cool - thanks!', bob 19:59:18 +Mark_Little 20:00:25 +Gilbert_Pilz 20:00:42 +[Sun] 20:00:46 agupta has joined #ws-addr 20:00:48 gpilz has joined #ws-addr 20:01:05 +Tom_Rutt 20:01:35 plh has joined #ws-addr 20:02:00 prasad has joined #ws-addr 20:02:06 +Plh 20:02:06 TRutt_ has joined #ws-addr 20:02:22 PaulKnight has joined #ws-addr 20:02:38 +Paul_Knight 20:02:45 zakim, [Sun] is me 20:02:45 +agupta; got it 20:02:58 anish has joined #ws-addr 20:03:13 zakim, ??p6 is MarcG 20:03:17 +MarcG; got it 20:03:35 +Anish_Karmarkar 20:03:49 +Paul_Downey 20:04:16 +Prasad_Yendluri 20:04:39 Observer+ Doug Davis (IBM) 20:04:45 +[IBM] 20:04:55 Paco has joined #ws-addr 20:05:35 +[IPcaller] 20:05:52 zakim, mute me 20:05:52 David_Illsley should now be muted 20:06:27 dorchard has joined #ws-addr 20:06:36 zakim, IPcaller contains Katy 20:06:36 +Katy; got it 20:06:48 +Dave_Hull 20:06:52 dhull has joined #ws-addr 20:06:58 Katy has joined #ws-addr 20:08:19 scribe David Hull 20:08:26 Scribe: dhull 20:08:28 scribe: David Hull 20:09:16 bob: One item not on agenda: I have been asked by Policy chairs about potential of joint task team for working out policy assertions for WSA 20:09:35 bob: Today's proposal moves in that direction. 20:10:02 q+ 20:10:11 philippe: Will this slow us down? 20:10:14 bob: Don't know 20:10:55 anish: Seems like good idea. Had some discussion with UsingAddressing. Say it can be used as a policy assertion. Shouldn't take long to come up with such an assertion, as we already have something ready. 20:11:11 Anish: Can also say that XMLP has been asked for similar effort regarding MTOM 20:11:27 Bob: how about drafting one and throwing it over the fence for review? Or should we work jointly? 20:11:47 Dhull: Prefer throwing it over the fence. 20:12:01 Bob: There being no objection, let's take that tack. 20:12:22 Bob: No addtions to agenda; agenda stands as is. 20:12:32 q- 20:12:33 q+ 20:12:40 Bob: Approval of minutes. Any objections? 20:13:03 Tom: Editorial error in header number in issue number (same in both headers). Is this important? 20:13:20 Bob: Will check before posting. Other issues? 20:13:31 ack tru 20:13:38 Bob: I will review minutes then post them. 20:14:06 Bob: AIs (beyond constant plea for more WSDL testers -- speak right up ...) 20:14:10 Omnes: Dead silence 20:14:18 Bob: AI Tony to complete table. 20:15:44 Tony: Working on it. [gives an example referencing instead of copying rule 5]. Noting that faults may be returned even when anon is prohibited if headers aren't proceesed yet. 20:16:24 Bob: New issues: Wanted to raise possibility of generating primer/FAQ. What do folks think? 20:16:38 Crickets: Chirp, chirp 20:17:07 Gil: Sounds like a good idea. I've had to explain WSA to customers in past, what it is, what it solves. Would be useful. 20:17:16 Bob: Who would write it. 20:17:27 Katy: Great idea, but it will be hard to get someone to find time. 20:17:32 MGoodner: WOuld not have time. 20:17:49 Arun: Very good idea. Have blogged about it, but do not have time. 20:17:53 sent my 2p worth to the list: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0011.html 20:18:03 I could spend some time on a WS-A primer 20:18:22 Bob: Arun, is there anything you've already done you could contribute? 20:18:29 Arun: Could send it later this week. 20:19:02 Bob: Gil, could you look it over and get scope of effort? 20:19:04 Gil: Yes 20:19:22 Bob: Good. At least want to stop questions to "Guru" about where to send faults. 20:19:51 Bob: Now to the main event, CR33. 20:20:09 Bob: When we left off we were discussing Paco & Anish's proposal. 20:20:42 +DOrchard 20:20:54 Paco: Simple proposal for A6 on our list. Requires no changes to core, just cover anon assertion in WSDL. 20:22:09 Paco: There are two proposals. We prefer option 1. Three options: WSA fully supported, WSA supported but all responses over backchannel, WSA supported but no backchannel responses. 20:22:33 Paco: We assume backchannel exists and is identifiable for some transports. 20:22:56 Paco: Option 1: Get rid of wsaw:Anonymous and wsaw:UsingAddressing 20:22:59 yinleng has joined #ws-addr 20:23:25 Paco: Option 2: Keep wsaw:UsingAddressing, default is fully supported, options for other tow possibilities. 20:24:04 +??P19 20:24:11 zakim, ??p19 is me 20:24:11 +yinleng; got it 20:24:24 Anish: Wanted to reiterate that this is quite in line with WS-Policy request. Also, had some suggestions for names but didn't converge. We can always discuss this. Better suggestions welcome. 20:24:48 Bob: We can always talk about names separate from concept. What do people feel about concept. 20:25:08 Pins: Drop noisily 20:25:21 Bob: Does this completely resolve CR33? 20:25:29 Anish: We think so. 20:25:51 Bob: How do we reconcile this with string compare wording in core spec? 20:25:52 zakim, who is noisy? 20:26:01 someone has a speakerphone on 20:26:09 Anish: Looking ... 20:26:09 pauld, listening for 11 seconds I heard sound from the following: Anish_Karmarkar (16%), [IBM] (42%), DOrchard (25%) 20:26:14 Paco: Need to refresh memory 20:26:15 zakim, whi is making noise 20:26:15 I don't understand 'whi is making noise', bob 20:26:18 zakim, who is noisy? 20:26:26 q+ 20:26:33 pauld, listening for 10 seconds I heard sound from the following: 19 (19%), Bob_Freund (95%), DOrchard (28%) 20:26:40 q+ 20:27:09 Dug: THink the string compare is orthogonal issue. Paco's proposal just says "however you determine it, this tells you whether you can". 20:27:29 Paco: Can't recall anything relevant to stirng compare (?) 20:27:34 zakim, who is noisy? 20:27:42 ack dug 20:27:49 ack anish 20:27:50 pauld, listening for 11 seconds I heard sound from the following: Anish_Karmarkar (86%), DOrchard (12%) 20:28:11 Anish: I agree with dug and paco. I assume you're talking about 3.2.1 that says that comparing address is just a string compare. Don't think that's relevant because we're talking about backchannel, not anon. 20:28:13 q+ 20:28:30 Anish: THis marker means service has this capability. 20:28:37 ack dhull 20:28:42 zakim, who is noisy? 20:29:00 dorchard, listening for 10 seconds I heard sound from the following: Bob_Freund (0%), Dave_Hull (90%), DOrchard (28%), Plh (0%) 20:29:05 Dhull: not passionately against this proposal, but feels that the ground is a bit slippery 20:29:29 mute, dorchard 20:29:30 zakim, mute me 20:29:30 DOrchard should now be muted 20:29:56 q+ 20:30:50 Dhull: made a proposal to have a way to place information in the address field to mark as to purpose 20:31:10 dhull: use regex to recognize the uri 20:31:32 q? 20:32:14 Dhull: "backchannel" creates a bit of problem of scope 20:32:54 Paco: Responding to question about "what does backchannel mean". Shouldn't be a problem. Everyone knows what it means for HTTP. It should be part of defining a binding for a transport to be used with WSA. 20:32:55 -Mark_Little 20:33:02 would be nice to have a non-HTTP example 20:33:30 Bob: Would this work for you, Dug? 20:33:53 q+ 20:34:05 Dug: Looks like either would work. Not sure about David's, need to grok it. Would probably work. Leaning toward Paco's 20:34:06 ack paco 20:34:11 ack anish 20:34:40 +1 as to scheme attribute 20:35:13 Anish: Need to evaluate it. Interesting thing is scheme attribute, which says what protocols are used. This is a requirement that came up in Async TF, think we decided it was a good requirement. For whatever reason this never made it to mainstream. This proposal provides this as add'l feature. 20:35:36 q+ 20:35:46 ack mrg 20:36:10 MGoodner: Wondering if nested assertions were considered. E.g., backchannel as sub-assertion of WSA supported. 20:36:42 Anish: Did consider it. Don't remember details of why we ended up thinking that independent assertions would be better. 20:37:40 Paco: Was some discussion. Recommendation of Policy was either fully nested, or capture meaning at top level so intersection was more meaningful. This is WS-Policy best practice. Mark, do you see an advantage to nesting? 20:38:06 MGoodner: Not yet, but these seem like further qualifications of WSA supported. But only had time for a quick look. 20:38:37 Paco: Actually option 2 is very much along those lines. Would leave using addressing, other markers qualify them. Marker also remains in WSDL (independent of policy). 20:39:01 MGoodner: Do policy guidelines talk about whether nesting would be appropriate? 20:39:16 Paco: DOn't know. Separate assertions seemed better. 20:39:37 Bob: Is this general direction something folks are comfortable. 20:39:44 Tony: Can live with it? 20:39:53 ?: Option 1 or option 2? 20:39:59 Bob: General direction. 20:40:08 s/\?/Dug/ 20:40:58 Bob: Am I correct in understanding that WSDL marker gives general control, policy can give finer control. 20:41:15 Anish: Thought we were using same tack as before. These can be either WSDL or policy assertions. 20:41:30 Paco: THink people will move to policy, but this allows for grandfathering 20:41:39 Bob: So we mirror in either WSDL or Policy 20:41:41 Anish: Yes 20:41:54 Bob: So given sub-options here, which way do we go? 20:42:13 Bob: (Looking at Paco's most recent email) 20:42:23 Bob: Paco, what do you recommend 20:42:43 Paco: Option 1 is much cleaner. Doesn't split between WSDL and policy. Can still use WSDL markers 20:43:14 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0094.html 20:43:14 http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0094.html 20:43:38 q+ 20:43:45 MGoodner, Warning against nesting: Last sentence of http://www.w3.org/TR/2006/WD-ws-policy-20060927/#rPolicy_Assertion 20:43:47 ack mrg 20:44:04 MGoodner: Policy assertions only without WSDL markers? 20:44:42 Paco: Email just proposed three policy assertions. May be WSDL markers. May use just policy or just WSDL. Helps people who don't yet support policy. I'm OK with that. 20:44:46 q+ 20:44:53 zakim, unmute me 20:44:53 DOrchard should no longer be muted 20:45:04 Bob: This would move us back to LC, right? 20:45:20 Philippe: Yes, it would. 20:45:30 ack dorc 20:45:41 DaveO: Does this marker appear any place UsingAddressing can be used? 20:45:45 Paco: Yes 20:45:48 q+ 20:45:56 DaveO: Effectively, take any place UA is used and put this in 20:46:00 ack mrg 20:46:00 Paco: Yes, you can. 20:46:18 MGoodner: What would be impact of using option 2, additively? STill LC? 20:46:41 Bob: You mean adding two add'l WSDL markers? 20:46:46 Mgoodner: Right 20:47:07 MGoodner: Does this change LC 20:47:18 Bob: Design change, not editorial change 20:47:30 MGoodner: E.g., could new elements go into new namespace? 20:47:37 Bob: Maybe. Philippe? 20:47:57 q+ 20:48:05 Anish: Remove anon, add two new? 20:48:22 Bob: Proposal is publish what we have, then publish 1.1 with addition in new namespace. 20:48:38 MG: Was proposing keeping existing namespace, new namespace for new elements 20:48:49 Anish: Remove wsaw:anon from existing namespace 20:48:58 MG: DOn't know, just trying to understnd 20:49:16 Anish: Either way ahve to get rid of wsaw:Anon. What would it mean to remove element and keep namespace? 20:49:22 ack katy 20:49:54 q+ to say that removing would be an incompatible change as there would be unexpected behaviour 20:50:20 zakim, mute dorchard 20:50:20 DOrchard should now be muted 20:50:22 Katy: Before we actually add these, should check for requirement. 20:50:41 Katy: If we remove wsaw:anon, we will have a namespace change as there is interop issue 20:50:49 ack dorch 20:50:50 zakim, unmute dorchard 20:50:51 dorchard, you wanted to say that removing would be an incompatible change as there would be unexpected behaviour 20:50:56 DOrchard was not muted, pauld 20:51:56 DaveO: Understood that old version would see new marker and wouldn't know what to do. But in practice things may be fine because service with new version would never use new (?) name and client wouldn't see it. Typically removing from namespace is incompatible, as is changing cardinality (which this is) 20:52:00 Anish: My concern to. 20:52:15 Bob: Seems like breaking change to me. Pub rules would move us back to LC, new namespace. 20:53:02 q+ 20:53:04 DaveO: Thinkig it over more. Typically removing is incompatible because someone will have older version which will see larger allowable set and will take advantage and send it. But WSDL is service-oriented. IF client has old version, server new, then the server just won't use the new version. 20:53:58 q+ 20:53:58 q+ 20:54:10 ack plh 20:54:15 DaveO: So old client will wokr with noew service. BUt old client could see it from new service. Our rules say client would ignore. Would that be OK? Point being, looks like breaking change, but due to our architecture it might not be. Havne't thought about "out" operations, jsut "in-out". Might want to tthink it over. 20:54:36 q+ plh 20:55:10 Anish: Taking it a bit further. We would wsaw:UA, two more qnames, not anonymous. Old version has US, anon. If you see wsaw:anon, newer QName, have older client, what should client assume? Full support? Backchannel? 20:55:59 DaveO: Would be interesting set of use cases to run. Can't run through it in real time here. WOuld be useful experiment to try. Old/new client/server against various setting of the params. Can't see failure case off the top of my head. 20:56:12 Bob: So if we propose it's a non-breaking change, show analysis. 20:56:19 ack plh 20:56:20 DaveO: If it's a breaking change, show the break. 20:57:00 Philippe: If we're introducing new elements, we should give other groups a chance to review, so we should go to LC. Not the end of the world. Can do CR stuff in the interim. 20:57:02 ack mrg 20:57:40 MG: Analysis of whether it's a breaking change would be interesting. Believe we're using UA feature right now, so want to understand feature. IF there's a non-breaking way to keep it and add on, want to explore that. 20:58:15 q+ 20:58:26 MG: IF there's a request from WSP to define assertion, if it wasn't a breaking change to lose anon etc., could't those assertions be defined there, not here? (i.e. in new document). Wasn't that th requeest. 20:58:29 Bob: Not sure 20:58:36 ack anish 20:59:30 Anish: Whether separate doc or not, I imagine that these markers would be dual-purpose (WSDL or Policy), as already discussed, to allow persons without policy support to specify functionality. So would have to be in WSDL doc for sure, so they keep in sync. 21:00:03 Katy: Could consider removing wsaw:Anon and keeping these markers. Would cause namespace change, but better for long term. 21:00:07 Bob: Feels cleaner to me. 21:01:17 DaveO: Not convinced that adding things into an existing namespace automatically means new namespace. Gets down to compatibility, whether right behaviours can happen. If it's a compatibile change, new QNames can go into same namespace. I'm a fan of that namespace versioning policy. So need to do analysis on both ends. 21:01:58 Bob: You've convinced me of need for more analysis with your earlier points. Need to run the scenarios. Also need to see if namespaces would get tangled. 21:02:18 q+ 21:02:35 Bob: Is this the approach we need to solve CR33. Get the sense that option 1 is the way to go but need to do more legwork, analysis, due diligience on namespace issue. 21:02:36 ack mrg 21:03:10 MG: Don't want to rule out option 2, as we're using UA currently. Want to understand analysis of possible breaking change. Wnat to compare option 1 vs. 2 here. 21:03:34 MG: Also not sure whether it's appropriate to say backchannel without even mentioning anonymous. 21:04:18 q+ 21:04:37 Anish: The proposal is specifically designed to do that, because of problems on past calls. Restricting to specific wsa:Anon is not enough because of None URI, and other specs can come up with others. So this was meant to capture that and talk about backchannel independent of how it's reflected in EPR address. 21:04:42 ack mrg 21:05:24 MG: BUt that's not all of the opinions expressed. Some said that the extra URIs were not appropriate to begin with. Need to think it over more, wanted to air concern. 21:05:26 if the URI is mentioned as an example then its ok but if its mentioned as the only URI then CR33 is not closed. 21:05:37 s/closed/resolved/ 21:05:39 Bob: P & A, are you willing to take this further. 21:05:59 Anish: Need to talk about what kind of wordings we want, and the sort of analysis that DaveO mentioned. 21:06:14 you need to say somthing about what qualifies as "a backchannel" or you are just opening up a whole universe of interop problems 21:06:59 "as defined by the transport" or something like that - but mentioning specific URIs doesn't address the issue 21:07:21 Bob: My understanding is we have option 1 that several like, option 2 that some want left on table, need two further analyses -- what breaks, what impact on namespaces w.r.t. WSDL binding. Third thing is detailed exam of existing specs (i.e., core) for inadvertent conflict. Finally, need proposed text for policy assertion and WSDL. 21:07:23 (I should say "mentioning" and "limiting the URIs") 21:07:55 q+ 21:07:56 gpilz, I'm not sure I agree, surely a client knows what backchannels are available to it? 21:08:18 Dug: If we modify the proposal to say what "backchannel means" and it's just anon, we haven't addressed CR33. If anon is an example, that's fine. 21:08:24 ack gil 21:08:28 (so who says if some other URI is backchannel?) 21:08:39 ack gp 21:09:18 Gil: How does client evaluate "backchannel"? Client needs to know what server thinks it is. Otherwise it has to guess which URIs are OK. Has to be some way for client to figure out what this service will or will nto accept. 21:09:36 Paco: This is a per binding/transport thing. You need to define a lot of things with a binding anywya. 21:09:58 Gil: But if I'm using WSA anon I know what's up. But if I have some other URI, how do I know? 21:10:06 q+ 21:10:07 Paco: IF you're using the URI you know what it means. 21:10:15 Gil: I know what it menas, but not if it will be accepted. 21:10:32 Paco: You know it means use the backchannel, and you know if that's OK. YOu have enough information. 21:10:38 ack ani 21:10:42 Gil - wouldn't that be an RM issue? let RM define a policy assertion that says whether or not RManonURI is supported 21:11:00 Anish: If you want that level of precision, then you may want option A8, which changes core, or DaveH's proposal. 21:11:05 dug - that's an idea 21:11:09 Isn't RMAnon independent of transport? 21:11:31 q+ 21:11:31 Anish: Want to leave core alone and leave what backchannel means to the binding. 21:11:40 Bob: Meta-backchannel. Whatever it means to you. 21:11:51 gpilz, I was convinced earlier in the week that RM don't need a policy assertion as if it's supported there'll be a MakeConnection operation in the wsdl 21:12:17 (missed something) 21:12:21 ack gpil 21:12:27 david_I - true 21:12:37 q+ 21:12:52 Gil: Inclined toward this approach of skirting the issue of what qualifies or not, but does it introduce interop problems? 21:13:11 leave WSA simple and extensible 21:13:28 Bob: A year or so ago we talked about what we meant by backchannel. Concluded that the transport knows what it is and it is what it is. This moves a step more clearly in this direction. 21:13:32 ack mrg 21:13:44 q+ 21:13:57 does the core spec already say Anon == backchannel? 21:14:36 ack paco 21:14:38 MG: Gil is identifying something here. To say backchannel but not mention address, particularly since we define anon, given that others may define other URI and go ahead and use it, seems concerning. Need to think it over. Doese seem odd not to mention the URI we have that means the backchannel. TO leave it open to others with just this marker doesn't seem right. 21:15:44 q+ 21:16:25 Paco: THe only reason why this issue is open is w.r.t. the URI you used. We have one particular solution that works and introduces other URIs that mean backchannel. But clients don't use URI in a vacuum. THey don't use them without knowing what they mean. They don't pick at random. You do RM because you know RM. It's like the question of whether you describe random headeres in WSDL,... 21:16:27 ...or give assertions that have behavior behind them. WE give assertions. 21:16:34 q+ 21:16:40 ack mrg 21:17:22 MG: Would agree more if RM URI were limited to RM uses. But it isn't, according to RM CD, which is publically available. Assuming RM is engaged is a wrong assumption. There are proposals in front of TC that compose with using wsa anon. 21:17:22 ack dug 21:18:18 q+ 21:18:23 +1 to dug 21:18:46 ack mrg 21:18:53 Dug: With respect to what URIs mean, WSA has defined what its own URI mean. IF some other spec defines its own URI mean, that's not WSA's job. If the spec that defines that URI wants clients and servers to know what its URI mean, that's its job. WSA just needs to define what its own URI mean, and an extensibility mechanism. Paco's proposal does this. It's up to other specs to define... 21:18:55 ...what backchannel means. 21:19:27 MG: So in WSA abstractly defining a marker that means backchannel, and WSA has defined anon, should we advice other specs to define a related marker for their URI. 21:19:56 Dug: Not a hard requirement, but couldn't hurt, whether or not new special URI are anonymous in nature. 21:20:06 MG: So how does none apply in this discussion of backchannel. 21:20:11 Dug: It doesn't. 21:21:03 Are we back to wsaw:Anonymous again? 21:21:16 Bob: In context of sync or async exchange, with WSA set up as it is w.r.t anon/none, the URI in the spec seem appropriate. Is it possible for us to say "we have mechanism that uses anon, anon means backchannel, if you want to extend meaning of backchannel, this is how you advertise it". So there's still a core of sync/async activity. 21:21:23 Bob: Sounds like primer material. 21:21:52 Bob: Any more that we can fruiitfully hash out without going into next level of detail? 21:22:16 Bob: A&P have next step to do. Do we want to keep option 2 on table? 21:22:38 MG: Yes. Especially w.r.t. analyzing for breaking change 21:22:46 Bob: Are you amenable? 21:23:04 Bob: i.e. to keeping Option 2 on the table for analysis. 21:23:13 Paco: THink that's fair. 21:23:20 Anish: Fine with it. 21:23:56 Anish: Would like to say that this analysis would be useful independent of backchannel issue, particularly since request was from WSP WG. 21:24:19 Bob: So we are done with CR33 discussion for today. 21:24:52 Bob: Or were any of the other options more attactive? 21:25:01 Omnes: Nada 21:25:29 Bob: AOB? 21:26:37 Paco: When do we need to do this? 21:27:05 Bob: Should have proposal out no later than Wed or Thu, otherwise call on 30 October would be a waste. 21:27:16 Paco: Happy to send this out by then. 21:27:28 MG: Should we give RX TC more time and come back in 2 weeks? 21:28:40 Bob: I could describe this as a general direction. Next RX TC call is Thu. Would that be fruitful, if it's OK with them. So we can go ahead with 30 Oct. Would like to close CR33 soonest. 21:28:48 Paco: Will have it out by Thu. 21:28:59 Bob: Next call October 30. 21:29:15 Tony: I have uploaded modified table for CR31, so we can discuss that. 21:29:22 Bob: CR33 will impact the table 21:29:25 Tony: THought it might. 21:29:47 Bob: Adjourned 21:29:47 -MarcG 21:29:49 -agupta 21:29:49 -[IBM] 21:29:51 -Tom_Rutt 21:29:52 -DOrchard 21:29:54 -Gilbert_Pilz 21:29:55 -yinleng 21:29:56 -Anish_Karmarkar 21:29:57 -Paul_Knight 21:29:58 -David_Illsley 21:30:00 -TonyR 21:30:05 -Dug 21:30:06 -Dave_Hull 21:30:08 agupta has left #ws-addr 21:30:08 -Bob_Freund 21:30:09 -Plh 21:30:13 -Prasad_Yendluri 21:31:53 TonyR has left #ws-addr 21:32:01 yinleng has left #ws-addr 21:32:31 -[IPcaller] 21:32:49 rrsagent, make logs public 21:33:25 rrsagent, generate minutes 21:33:25 I have made the request to generate http://www.w3.org/2006/10/23-ws-addr-minutes.html bob 21:35:09 action: paco and anish to do a further analysis leaving open both options 1 and 2 with respect to breaking changes and namespace issues 21:35:28 Dug has left #ws-addr 21:35:45 action: arun to publish what he has to the group as a starting point (possibly) for a primer 21:35:58 rrsagent, generate minutes 21:35:58 I have made the request to generate http://www.w3.org/2006/10/23-ws-addr-minutes.html bob 21:38:23 TRutt_ has left #ws-addr 21:38:44 action: bob to describe this general direction to the RX TC on the Thursday teleconference 21:38:52 rrsagent, generate minutes 21:38:52 I have made the request to generate http://www.w3.org/2006/10/23-ws-addr-minutes.html bob 21:39:22 scribenick: dhull 21:39:31 rrsagent, henerate minutes 21:39:31 I'm logging. I don't understand 'henerate minutes', bob. Try /msg RRSAgent help 21:39:41 rrsagent, generate minutes 21:39:41 I have made the request to generate http://www.w3.org/2006/10/23-ws-addr-minutes.html bob 21:44:36 bob has left #ws-addr 22:05:01 disconnecting the lone participant, Paul_Downey, in WS_AddrWG()4:00PM 22:05:02 WS_AddrWG()4:00PM has ended 22:05:06 Attendees were Bob_Freund, TonyR, +44.196.286.aaaa, David_Illsley, Dug, Mark_Little, Gilbert_Pilz, Tom_Rutt, Plh, Paul_Knight, agupta, MarcG, Anish_Karmarkar, Paul_Downey, 22:05:08 ... Prasad_Yendluri, [IBM], Katy, Dave_Hull, DOrchard, yinleng 23:41:29 Zakim has left #ws-addr