19:59:07 <RRSAgent> RRSAgent has joined #ws-addr
19:59:07 <RRSAgent> logging to http://www.w3.org/2007/04/23-ws-addr-irc
19:59:16 <Zakim> Zakim has joined #ws-addr
19:59:42 <Ram> Ram has joined #ws-addr
20:00:07 <bob> meeting: WS-Addressing WG Teleconference
20:00:13 <bob> chair: Bob Freund
20:00:24 <mlittle> I can scribe today Bob
20:00:44 <bob> zakim, this will be #WS_ADDRWG
20:00:44 <Zakim> I do not see a conference matching that name scheduled within the next hour, bob
20:00:59 <bob> scribe mlittle
20:00:59 <TonyR> zakim, this is addr
20:00:59 <Zakim> ok, TonyR; that matches WS_AddrWG()4:00PM
20:01:19 <TonyR> zakim, who is on the phone?
20:01:19 <Zakim> On the phone I see [Microsoft], Mark_Little, Bob_Freund, Dave_Hull, ??P4, Tom_Rutt
20:01:27 <TonyR> zakim, ??p4 is me
20:01:27 <Zakim> +TonyR; got it
20:01:43 <bob> zakim [Microsoft] is ram
20:02:17 <Katy> Katy has joined #ws-addr
20:02:26 <bob> zakim, [Microsoft] is ram
20:02:26 <Zakim> +ram; got it
20:02:43 <Zakim> +??P6
20:02:51 <anish> anish has joined #ws-addr
20:02:59 <bob> zakim, ??P6 is katy
20:02:59 <Zakim> +katy; got it
20:03:24 <Zakim> +Anish_Karmarkar
20:03:39 <gpilz> gpilz has joined #ws-addr
20:03:53 <Zakim> +Gilbert_Pilz
20:04:25 <plh> plh has joined #ws-addr
20:04:29 <Zakim> +Plh
20:04:33 <Zakim> +m2
20:05:07 <bob> zakim, m2 is monica
20:05:07 <Zakim> +monica; got it
20:05:09 <monica> monica has joined #ws-addr
20:06:51 <mlittle> topic: approval of minutes
20:07:14 <mlittle> chair: minutes accepted, no objections.
20:07:25 <PaulKnight> PaulKnight has joined #ws-addr
20:07:42 <mlittle> chair: insert new item into agenda - sent to working group WS-Policy working group response to our lc133
20:07:59 <mlittle> rofl
20:08:09 <anish> PCNF?
20:09:57 <TRutt__> q+
20:10:00 <mlittle> chair: can we agree that chair's efforts to form a reasonable response to last call commentary?
20:10:35 <mlittle> anish: accepted proposal g by accepting 2 more issues. Is what we expect from WS-P affected by this?
20:10:38 <Zakim> +Paul_Knight
20:11:47 <mlittle> chair: 2 new issues (from Anish). One of them scope of policy subject (specification or something else). These are issues that arose subsequent to adopting g. It may or may not affect them. Unknown at this time.
20:11:51 <bob> ack tr
20:12:22 <mlittle> trutt: agrees that those issues came up after. Wants to send this to the WS-P group now and see what their response is.
20:12:58 <mlittle> anish: happy to do so. Wants to see if this response addresses WS-P concerns.
20:13:29 <mlittle> trutt: thinks we can accommodate any changes due to other issues later.
20:14:12 <mlittle> chair: having a call with policy chairs weekly. WS-P doesn't see anything from WS-A that they can act on at this time. Hope that this response is something that they can act on.
20:15:07 <mlittle> +1
20:15:32 <mlittle> chair: any objections to submitting this draft?
20:15:59 <TRutt__> q+
20:17:00 <bob> acl tru
20:17:09 <bob> ack tru
20:18:15 <mlittle> trutt: maybe monica can comment, but policy group is already using alternative g in discussions. We should be asserting that this is what we want. We make definitive statements about the semantics of empty. At this point, until/unless ws-p comes up with something better this is the way we should go. But am happy to take something else from ws-p group.
20:18:44 <monica> where are these questions and responses, bob?
20:19:00 <mlittle> chair: if we have specific issues with ws-p then raise issues against them in policy bugzilla.
20:19:16 <mlittle> chair: questions and responses should be in bugzilla.
20:20:10 <mlittle> chair: any further discussion?
20:20:25 <mlittle> RESOLUTION: to send response to WS-P as defined.
20:20:54 <mlittle> topic: lc134
20:21:14 <bob> http://www.w3.org/2002/ws/addr/lc-issues/#lc134
20:22:03 <mlittle> anish: AI not completed from last time. Apologies.
20:22:20 <mlittle> chair: defer to next time?
20:23:30 <mlittle> chair: explains reading of lc134. Proposal might be close with no action. Would that sound right?
20:23:56 <mlittle> anish: does not dispute that that would make sense. However, we would still need to clarify in the spec that the assertion means compliant with both specifications.
20:24:16 <mlittle> chair: OK. But will we have concrete text for next week? Want to get into 2nd last call next Monday.
20:24:21 <mlittle> anish: agrees.
20:24:42 <mlittle> topic: lc135
20:25:58 <TRutt__> q+
20:26:10 <mlittle> anish: when we accepted g we said that if you had ws-a top level address assertion with no nested assertions it means no restrictions on the endpoint. this could be interpreted as meaning it supports anon and non-anon. Another interpretation could be that it supports ws-a and no other additional claim is made. there are well defined soap faults that can sent if either anon or non-anon is supported and you can try them and see what happens. Anish likes that 
20:26:36 <mlittle> anish: because such a definition can be quite useful.
20:26:50 <mlittle> anish: thinks Tom (Rutt) takes us to proposal f.
20:26:59 <Katy> q+
20:27:08 <mlittle> trutt: no, going back to original supports stuff, where empty says nothing (e).
20:27:21 <mlittle> trutt: empty means no responses are supported at all.
20:28:04 <mlittle> anish: anon and non-anon nested assertions cannot occur within the same ws-a top-level assertion. that would have to change if we remove this restriction. you may want to say that anon and non-anon are definitely supported.
20:28:20 <mlittle> trutt: biggest problem is interpretation won't work with intersection.
20:28:30 <mlittle> anish: wants clarification.
20:29:01 <anish> q+
20:29:04 <mlittle> trutt: current definition supports intersection. it's designed to work with the ws-p algorithm.
20:29:04 <bob> ack tru
20:29:08 <bob> ack katy
20:29:22 <mlittle> katy: how could you positively support that you support anon and non-anon?
20:29:44 <mlittle> katy: thinks it has been covered by anish. Agrees that we should stay as we are.
20:30:30 <mlittle> anish: in that case, how do you create a policy that supports ws-a and ws-a soap binding? without saying anything about whatever else is not mandated by the spec.
20:30:41 <mlittle> chair: you'd simply say addressing?
20:31:01 <mlittle> anish: if we just say addressing, it means that you support anon and non-anon.
20:32:16 <TRutt__> q+
20:32:39 <mlittle> anish: nowhere does it say that you have to support non-anon and anon. they aren't always applicable. this is forcing me to create a new assertion. understand that anon and non-anon are important for interaction patterns. But thinks issue gives that as well.
20:32:44 <bob> ack ani
20:32:51 <bob> ack tru
20:32:59 <anish> q+
20:33:16 <mlittle> trutt: thinks that anish is arguing something else entirely. Didn't think new nested assertions were ever going to be added. make non-anon and anon first level assertions?
20:33:19 <monica> doesn't ws-a metdata element in the core spec indicate that metadata could be more than ws-am? 
20:33:48 <mlittle> anish: not envisioning that new nested assertions will be allowed. Or making them top-level assertions.
20:34:31 <mlittle> anish: wants to say that only specific URIs are supported for responses and non-anon is too broad for that. Does not want to advertise non-anon in that case.
20:34:54 <mlittle> trutt: but that's already defined. non-anon doesn't mean you support any non-anon URI.
20:36:29 <monica> q+
20:36:56 <TRutt__> Anish is actually asking for what is in the LC draft
20:37:08 <TRutt__> q+
20:37:57 <bob> ack anish
20:38:13 <mlittle> anish: wants assertions to be composable. Not defining new ones.
20:39:17 <bob> ack monica
20:40:03 <mlittle> monica: in the metadata element is optional. Is what anish wants a metadata element that is not scoped to what the metadata spec?
20:40:37 <mlittle> anish: not sure why metadata element is being brought up. Metadata in EPR?
20:40:41 <mlittle> monica: yes.
20:40:51 <mlittle> anish: thinks discussion is independent of this.
20:41:05 <mlittle> monica: not sure what the baseline assertion is. Confused by discussion (on both sides).
20:41:21 <Katy> q+
20:41:29 <mlittle> anish: policy assertion that is independent of the attachment mechanism. That's why the metadata element is irrelevant.
20:41:31 <bob> ack tru
20:41:47 <anish> q+
20:42:59 <mlittle> trutt: you want an assertion that is not nested within ws-a, correct? thinks what anish wants is already in the lc spec. but it doesn't work with the intersection algorithm.
20:43:07 <mlittle> anish: asks for clarification.
20:44:46 <dhull> so if I intersect "I support addressing" with "I support addressing; I support anon", I get "I support addressing", right?
20:46:13 <mlittle> trutt: believes that option f is the right one.
20:46:18 <bob> ack katy
20:46:31 <Ram> q+
20:46:46 <mlittle> katy: agrees with Tom that this is going backwards. Need way of saying "I support everything". More important that "I'm not going to tell you what I support."
20:47:33 <mlittle> chair: agrees
20:47:49 <mlittle> anish: wouldn't katy be supported by allowing inclusion of both nested assertions.
20:48:01 <mlittle> katy: yes, but why would we go back several weeks?
20:48:25 <TRutt__> q+
20:48:27 <mlittle> anish: doesn't understand rational for change several weeks ago. For the intersection algorithm?
20:48:55 <mlittle> trutt: we decided use case of no responses wasn't important. If you say that was wrong, we go back to f.
20:49:21 <mlittle> trutt: f lets you do that (more verbose than g). Would be happy to go back to f.
20:49:24 <bob> ack anish
20:49:25 <dhull> q?
20:49:52 <bob> ack ram
20:49:53 <mlittle> ram: maybe what anish wants is a clear definition of what it means to say "I support WS-Addressing". Correct?
20:49:54 <dhull> q+
20:51:17 <mlittle> chair: what specification would you support that is independent of anon and non-anon?
20:51:36 <mlittle> anish: wants to distinguish between definitions/what they mean and necessarily supporting them.
20:51:51 <Ram> q+
20:52:29 <bob> ack tru
20:52:53 <mlittle> trutt: just re-asserts that f is what anish wants. g is not.
20:53:11 <bob> ack dhull
20:54:28 <mlittle> dhull: would rather see none put with non-anon. prohibited, required, don't care give 9 possible options. would like to see a table for f and g (h?) and see how they deal with them.
20:54:30 <mlittle> +1
20:55:03 <bob> ack ram
20:55:32 <TRutt__> I do not understand a "don
20:55:39 <TRutt__> t care use case
20:55:56 <mlittle> ram: why are we trying to be selective on what it means to support ws-a?
20:56:50 <TRutt__> q+
20:57:02 <anish> +1
20:57:16 <Ram> q+
20:57:19 <bob> ack tru
20:57:38 <dhull> q+
20:57:54 <mlittle> trutt: crucial that don't care can be supported by f and g (for client). but why should a server ever want to assert don't care?
20:58:25 <mlittle> trutt: does not see a use case for a server saying I'm not going to tell you I do anon or non-anon.
20:58:35 <bob> ack ram
20:59:13 <anish> +q
20:59:49 <mlittle> ram: let's agree on what "I support WS-A" means. then apply that to single tl assertion. then qualify that on anon/non-anon.
21:00:05 <TRutt__> q+
21:00:58 <mlittle> trutt: use case of server that doesn't support responses was deemed not needed. hence dropping f and going with g.
21:01:45 <Katy> q+
21:02:06 <Ram> q+
21:02:30 <bob> ack dhull
21:03:19 <mlittle> dhull: can see case for no responses/non-anon only at server.
21:05:18 <bob> ack ani
21:05:50 <mlittle> anish: trutt asserted that common case would be both supported? does not agree. thinks anon would be more common.
21:08:36 <TRutt__> addressing with non anon and requiring make connection does what anish wants
21:08:57 <bob> ack tru
21:09:49 <mlittle> anish: agrees with tom.
21:09:49 <bob> ack katy
21:10:45 <mlittle> katy: go back to before cr33 and have definition that "I support ws-a" means everything in the spec until this restriction came along (anon versus non-anon).
21:10:51 <Zakim> -Paul_Knight
21:11:03 <anish> q+
21:12:08 <mlittle> katy: thinks we should stay as we are.
21:12:14 <mlittle> chair: no reason to re-open lc133?
21:12:16 <bob> ack ram
21:12:17 <mlittle> katy: agrees.
21:13:17 <Katy> I agree with Ram - new requirements should be clarified in new issues
21:13:20 <anish> what usingAdressing said:
21:13:21 <anish> If WS-A is engaged, use of the message addressing properties MUST be fully compliant with this specification; in particular, senders MUST use all message addressing properties mandated by the Web Services Addressing 1.0 - Core[WS-Addressing Core], applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding]), and this specification, and MUST follow all applicable WS-Addressing normative requiremen
21:14:18 <Ram> q+
21:14:26 <bob> ack ram
21:14:26 <anish> q-
21:14:30 <TRutt__> q+
21:14:55 <Ram> q+
21:14:59 <dhull> q+
21:15:59 <mlittle> anish: described his understanding of definition of usingAddressing.
21:16:05 <TRutt__> AnonOnly, NonAnonOnly, NoResponsesAllowed could be three separate top level assertions, with neither present being "nothing stated"
21:16:26 <TRutt__> q+
21:16:43 <mlittle> chair: what is different from g and usingAddressing text for tl assertion?
21:17:01 <dhull> q-
21:17:08 <mlittle> anish: difference is that usingAddressing is conformance to ws-a. But g is conformance plus that anon and non-anon are allowed.
21:17:26 <bob> ack tru
21:18:00 <mlittle> trutt: thinks this is a valid assertion, but we should pull out anon/non-anon as tl assertions for composability.
21:18:11 <Katy> q+
21:18:14 <mlittle> chair: could anish and tom take point offline?
21:18:52 <mlittle> chair: spent enough time going over this. g was agreed by group. No compelling information to go back on g.
21:19:15 <dhull> doesn't G disallow anon and non-anon together?
21:19:35 <anish> dhull, it does not allow them together
21:19:45 <bob> ack ram
21:20:18 <anish> i really think that using the usingddressing text makes thing composable
21:20:24 <mlittle> ram: believes text can be merged and come to agreement.
21:20:25 <Ram> q+
21:20:37 <bob> ack katy
21:20:44 <mlittle> trutt: does not know how text can be reconciled.
21:21:08 <mlittle> katy: is there a requirement for "I don't support anything"? There are requirements for non-anon/anon.
21:21:10 <mlittle> +1
21:21:41 <mlittle> chair: katy, let's have a vote and can you come up with the wording?
21:22:19 <mlittle> katy: full support, anon, non-anon only. Is there a requirement for "I support addressing but I don't say anything about whether I support anon or non-anon".
21:22:49 <Katy> Do we have a requirement to say "I support addressing but I don't say anything about my support for nonanon or anon responses"?
21:23:29 <mlittle> -1
21:23:33 <TRutt__> no
21:23:42 <dhull> yes
21:23:42 <Katy> no
21:23:43 <anish> yes
21:23:43 <Ram> NO
21:23:47 <gpilz> +1
21:23:50 <TonyR> abstain
21:24:26 <mlittle> 3 yes
21:24:28 <mlittle> 4 nos
21:24:55 <mlittle> chair: close vote, but can we close this?
21:26:11 <Ram> q+
21:26:54 <mlittle> 2 yes
21:26:56 <mlittle> 5 nos
21:27:00 <mlittle> 1 abstain
21:27:20 <mlittle> chair: believes that margin is now enough to close this.
21:28:04 <mlittle> chair: closed?
21:28:10 <mlittle> group: agrees.
21:28:26 <monica> may i make one comment
21:28:29 <mlittle> chair: so how does this vote affect open issues? lc135?
21:28:39 <mlittle> trutt: lc135 should be close no change.
21:29:54 <Ram> +1
21:29:58 <anish> so with this decision, if i want to match policy that says support for anon, then it would match a policy that only says <wsam:Addressing>
21:30:10 <mlittle> chair: group close lc135 no action?
21:30:22 <mlittle> RESOLUTION: lc135 closed no action
21:30:28 <bob> ack ram
21:30:52 <Ram> q+
21:31:51 <mlittle> chair: lc134 is last open issue. would like to get to lc again. incorporate resolution to lc133 into new editors draft of 1.0 metadata document so at next call we can have new resolution to get to lc.
21:31:55 <bob> ack ram
21:32:29 <TRutt__> q+
21:32:36 <gpilz> q+
21:32:45 <Ram> q+
21:33:17 <bob> ack tru
21:33:44 <Ram> Related text: The inclusion of the wsaw:UsingAddressing element indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing marker identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding].The presence of this eleme
21:33:44 <anish> q+
21:34:27 <bob> ack gpil
21:34:41 <mlittle> +1
21:34:59 <Ram> Anish: Are you fine with this text?
21:35:28 <anish> does that mean i can use this assertion on the portType?
21:35:42 <bob> ack ram
21:36:26 <TRutt__> I would clarify that I would be happy with a binding agnostic ws:addressing assertion type
21:36:59 <Ram> q+
21:37:13 <Ram> I propose that we allow both.
21:38:00 <TRutt__> q+
21:38:36 <gpilz> The presence of the wsam:Addressing assertion indicates that the applicable WS-Addressing specifications are supported. Specifically, when included in a SOAP binding, the wsam:Addressing assertion identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0
21:38:37 <mlittle> group: seems wrong to have to modify the specification to add support for new protocols.
21:38:43 <gpilz> - SOAP Binding[WS-Addressing SOAP Binding].
21:38:45 <bob> ack ram
21:38:52 <mlittle> chair: happier to have something that does not constrain the future.
21:38:53 <anish> q-
21:38:55 <anish> :-)
21:38:59 <mlittle> ram: proposes text as resolution.
21:41:06 <Ram> New Text: The use of the WS-Addressing policy assertion indicates that the applicable WS-Addressing specifications are supported and allows use of anonymous or non-anonymous URIs as addresses in an EPR. Specifically, when included in a SOAP binding, the WS-Addressing policy assertion identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing SOAP Binding].
21:41:11 <anish> for usingaddressing:
21:41:12 <anish> The wsaw:UsingAddressing element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only.
21:41:59 <gpilz> q+
21:42:09 <bob> ack tru
21:42:16 <dhull> s/EPR/Response EPR/
21:42:25 <TRutt__> Response to "(D) The WS-Addressing Metadata draft does not specify a 
21:42:25 <TRutt__> policy subject" 
21:42:25 <TRutt__> The policy subject has been identified as endpoint to wit: 
21:42:25 <TRutt__>  
21:42:25 <TRutt__> "The wsam:Addressing policy assertion applies to the endpoint policy 
21:42:26 <TRutt__> subject" 
21:42:28 <TRutt__>  
21:42:30 <TRutt__>  
21:42:33 <TRutt__> Response to "(E) The WS-Addressing Metadata draft should rule out 
21:42:34 <TRutt__> wsdl:portType and wsdl20:interface as possible attachment points." 
21:42:36 <TRutt__>  
21:42:38 <TRutt__> Such a prohibition has been included to wit: 
21:42:40 <TRutt__>  
21:42:42 <TRutt__> "A policy expression containing the wsam:Addressing policy assertion 
21:42:44 <TRutt__> MUST NOT be attached to a wsdl:portType or wsdl20:interface. The 
21:42:46 <TRutt__> wsam:Addressing policy assertion specifies a concrete behavior whereas 
21:42:48 <TRutt__> the wsdl:portType or wsdl20:interface is an abstract construct" 
21:43:23 <plh> q+
21:43:30 <anish> what this proposal means:
21:43:37 <bob> ack gpil
21:43:52 <anish> 1) assertion means core+soapbinding
21:44:02 <dhull> q+
21:44:03 <anish> 2) cannot be used on abstract wsdl
21:44:22 <anish> 3) (1) & (2) means cannot be used on a non-soap binding
21:44:39 <mlittle> This feels rushed. Why can't we go with the original action item and let Anish and Gill take this offline and come back next week? I'd prefer to get something to vote on that is well thought out and not just thrown together in 30 seconds ;-)
21:44:55 <monica> +1
21:45:09 <plh> q+ later
21:45:16 <plh> q-
21:46:25 <Ram> q+
21:46:37 <bob> ack dhull
21:47:36 <mlittle> Can someone take over scribe duty? I've got to go, unfortunately.
21:47:44 <bob> ok,
21:47:48 <bob> scribe: bob
21:47:49 <mlittle> sorry.
21:47:55 <Zakim> -Mark_Little
21:48:06 <dhull> brb
21:48:07 <bob> ack plh
21:48:10 <plh> q-
21:48:31 <yinleng> yinleng has joined #ws-addr
21:49:45 <Katy> q+
21:50:03 <Ram> q+
21:50:44 <Ram> +1 to Bob
21:51:28 <Katy> q-
21:51:31 <bob> Proposal:  Add to Section 3 the language " This assertion implies support for ws-addr core and soap binding.
21:51:47 <Ram> +1
21:51:53 <Katy> +1
21:51:58 <anish> yes, that makes sense, unless we satisfy gil's requirement
21:52:00 <dhull> +1
21:52:02 <Zakim> +YinLeng_Husband
21:52:07 <monica> should you use the work 'implies'?
21:52:34 <bob> s/implies/indicates
21:52:35 <dhull> How about "asserts"?  That's what assertions do, after all.
21:53:00 <monica> this is an issue to the baseline that applies
21:54:28 <Ram> q+
21:54:36 <Ram> Should we go LC today?
21:54:42 <anish> woo-hoo, now if ws-policy will just answer our questions
21:55:28 <Ram> Did we resolve and accept proposal G??
21:56:05 <bob> resolved: lc134 with "Add to Section 3 the language " This assertion implies support for ws-addr core and soap binding."
21:56:20 <Ram> Thank you.
21:56:53 <TRutt__> q+
21:58:26 <anish> q+
21:59:16 <bob> ack ram
21:59:37 <bob> ack ttu
21:59:47 <bob> ack tru
22:00:18 <Zakim> -TonyR
22:00:39 <bob> ack ani
22:02:16 <Zakim> -Anish_Karmarkar
22:02:20 <Zakim> -Gilbert_Pilz
22:02:22 <Zakim> -Tom_Rutt
22:02:22 <Zakim> -Bob_Freund
22:02:24 <Zakim> -monica
22:02:26 <Zakim> -ram
22:02:27 <Zakim> -Plh
22:02:29 <Zakim> -katy
22:02:31 <Zakim> -YinLeng_Husband
22:02:33 <bob> rrsagent, make logs public
22:02:42 <bob> rrsagent, generate minutes
22:02:42 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/23-ws-addr-minutes.html bob
22:02:49 <yinleng> yinleng has left #ws-addr
22:02:52 <Zakim> -Dave_Hull
22:02:53 <Zakim> WS_AddrWG()4:00PM has ended
22:02:55 <Zakim> Attendees were Mark_Little, Bob_Freund, Dave_Hull, Tom_Rutt, TonyR, ram, katy, Anish_Karmarkar, Gilbert_Pilz, Plh, monica, Paul_Knight, YinLeng_Husband
22:03:04 <plh> zakim, bye
22:03:04 <Zakim> Zakim has left #ws-addr
22:04:45 <plh> Tony, all sources are at http://dev.w3.org/cvsweb/2004/ws/addressing/
22:05:09 <plh> ie, you want http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.xml?rev=1.116&content-type=text/plain
22:05:32 <plh> note that you'll need the entities as well
22:05:41 <plh> otherwise your xml editor will complaint
22:05:45 <plh> s/t//
22:06:45 <plh> and if nothing work, fel free to stop by my office
22:06:49 <plh> s/fel/feel/
22:14:58 <TonyR> TonyR has left #ws-addr
22:16:06 <bob> philippe, are you there?
22:16:55 <plh> I am
22:17:28 <bob> how can i go back in the logs and make scribe think that mlittlt was scribe?
22:17:59 <plh> I don't think you do that online
22:18:19 <bob> shall I just go ahead and edit the html?
22:18:24 <plh> only way is to download the raw irc log, add the bits, and rerun the script
22:18:32 <bob> :-P
22:18:33 <plh> do you want me to do that?
22:18:41 <bob> That would be very nice
22:18:46 <plh> ok, give me two minutes
22:19:07 <plh> oh, actually, I have an other idea
22:19:17 <bob> ok
22:20:58 <plh> i/topic: approval of minutes/scribe: mlittle/
22:21:01 <RRSAgent> I have made the request to generate http://www.w3.org/2007/04/23-ws-addr-minutes.html plh
22:21:34 <bob> tghat worked, thanks
22:24:26 <bob> bob has left #ws-addr