19:41:45 RRSAgent has joined #ws-addr 19:41:45 logging to http://www.w3.org/2005/07/11-ws-addr-irc 19:41:55 zakim, this will be ws_addrw 19:41:55 ok, mnot; I see WS_AddrWG()4:00PM scheduled to start in 19 minutes 19:42:07 Meeting: Web Services Addressing Teleconference 19:42:11 Chair: Mark Nottingham 19:42:53 Agenda: http://www.w3.org/mid/96EB357F-9D88-430F-9FFC-E8EE1CCF9495@bea.com 19:49:44 mlpeel has joined #ws-addr 19:53:54 Katy has joined #ws-addr 19:54:52 Marsh has joined #ws-addr 19:55:03 TonyR has joined #ws-addr 19:57:06 Nilo has joined #ws-addr 19:57:34 WS_AddrWG()4:00PM has now started 19:57:40 +Mark_Peel 19:58:01 PaulKnight has joined #ws-addr 19:58:05 bob has joined #ws-addr 19:58:09 +Mark_Peel/Katy_Warr 19:58:49 +Bob_Freund 19:59:16 +Nilo_Mitra 19:59:33 +??P4 19:59:52 zakim, ??p4 is me 19:59:52 +TonyR; got it 20:00:26 +Andreas_Bjarlestam 20:00:27 +MarkN 20:01:09 -Bob_Freund 20:01:15 TomRutt has joined #ws-addr 20:01:17 +Hugo 20:01:24 prasad has joined #ws-addr 20:01:26 +Paul_Knight 20:01:39 +Bob_Freund 20:01:55 +Abbie_Barbir 20:02:03 +Umit_Yalcinalp 20:02:04 +??P11 20:02:07 pauld has joined #ws-addr 20:02:16 +Jonathan_Marsh 20:02:17 +Pete_Wenzel 20:02:18 -Umit_Yalcinalp 20:02:23 +Gudge 20:02:31 dhull has joined #ws-addr 20:02:31 +Umit_Yalcinalp 20:03:02 +dhull 20:03:03 +Tom_Rutt 20:03:04 +Prasad_Yendluri 20:03:21 uyalcina has joined #ws-addr 20:03:53 steve_winkler has joined #ws-addr 20:04:18 +Paul_Downey 20:04:20 Arun has joined #ws-addr 20:04:22 anish has joined #ws-addr 20:04:49 +Anish 20:05:00 +Marc_Hadley 20:05:07 +[Sun] 20:05:15 marc has joined #ws-addr 20:05:17 zakim, [Sun] is me 20:05:17 +Arun; got it 20:05:20 +DOrchard 20:06:31 scribe: dhull 20:06:45 +Vikas_Deolaliker 20:07:05 vinoski has joined #ws-addr 20:07:20 march: Status update. 20:07:34 (after AIs) 20:08:18 Corrections of minutes? 20:08:39 Minutes approved (no objection) 20:09:44 AIs: Anish, Umit done. DHull LC76: Needs to be more concrete. Due 15 July. 20:10:18 AI: LC107 (Marsh). Draft, not mailed yet. Editorial issue will be resolved. Marked as done. 20:10:33 AI: LC68 (marsh) Done. 20:11:14 Marc: Only issue not incorporated is 107. All other issues should be in editor's draft. Please let Marc know if that's not the case. 20:11:45 steve_winkler has joined #ws-addr 20:11:50 TOPIC: LC 104 20:11:52 vikas has joined #ws-addr 20:12:08 Anish has made proposal, discussion is active. 20:12:25 zakim, who is making noise? 20:12:31 Anish: Made draft of spec with abstract model of EPR. 20:12:35 +GlenD 20:12:36 mnot, listening for 10 seconds I heard sound from the following: Mark_Peel/Katy_Warr (4%), Bob_Freund (31%), Jonathan_Marsh (4%), Marc_Hadley (17%), Anish (68%) 20:12:59 GlenD has joined #ws-addr 20:13:22 andreas has joined #ws-addr 20:13:47 Anish: several +1s. Marsh would prefer to close no action but OK with it. There has bee nmore email in last 5 minutes. 20:14:14 MNot: Two related issues. Getting rid of abstract model for EPRs, and for MAPs. 20:14:16 +Mark_Little 20:14:22 Marsh: Only object to MAP part. 20:14:41 Anish: Issue is only about EPR, but did MAP too to see what it would look like. 20:15:20 q+ 20:15:54 Marsh: Collapsing EPR model makes sense. Collapses two concepts, not just sections of document. Infoset is not conveying that much extra information. Just isn't that much independent of the infoset. 20:16:18 q+ 20:16:22 Marsh: Anish has shown that collapsing will work. Bummer is that it's no longer consistent with MAP description. 20:16:36 Marsh: Not against getting rid of EPR section. 20:16:57 Mnot: Prasad, would you be OK with separating out EPR part, dropping abstract model in EPRs. 20:17:17 Prasad: No problem with that. 20:17:30 +??P30 20:17:49 Prasad: Some editorial inconsistencies to be taken care of. No objection to collapsing. 20:17:53 Anish: Where? 20:17:57 Prasad: Section 2.1 20:18:04 Mnot: So some editorial work. 20:18:23 Prasad: [address] in metadata, for example. 20:18:37 (missed much of the detail there) 20:18:44 q? 20:18:55 q+ 20:19:02 ack uyal 20:19:44 zakim, who is on the phone? 20:19:44 On the phone I see Mark_Peel, Mark_Peel/Katy_Warr, Nilo_Mitra, TonyR, Andreas_Bjarlestam (muted), MarkN, Hugo, Paul_Knight, Bob_Freund, Abbie_Barbir, ??P11, Pete_Wenzel, 20:19:48 ... Jonathan_Marsh, Gudge, Umit_Yalcinalp, dhull, Tom_Rutt, Prasad_Yendluri, Paul_Downey, Anish, Marc_Hadley, Arun, DOrchard, Vikas_Deolaliker, GlenD, Mark_Little, ??P30 20:19:54 q+ 20:20:18 Umit: Comment on MAP change. What does separate abstract model enable? In WSDL, we talk about includes, imports etc. No comparable concept with EPRs. In favor of collapsing. We should look at MAPs the same way: What benefit to additional layer that infoset does not cover. Can separate issues this way. 101 and 104 appear to be only EPRs, not MAPs. 20:20:23 uyalcina has joined #ws-addr 20:20:32 MNot: Anyone against EPR changes? 20:20:54 Paco?: Have some concerns about how it's written. 20:21:01 dorchard has joined #ws-addr 20:21:05 s/Paco?/Hugo 20:21:14 Katy: There are some advantages to abstract model, esp. for documenting. but not against collapsing. 20:21:18 ack marc 20:21:19 uyalcina has joined #ws-addr 20:21:27 q+ 20:21:28 q- 20:22:44 Marc: Same camp as Prasad. Not violently opposed, but like consistency with MAPs. As far as MAPs, have we broadened the discussion? (Mnot: No) Would be against for MAPs. No editorial problems. Some strange items to sort out, e.g., we're talking abougt address and metadata, not XML elements. 20:22:49 ack hugo 20:23:35 yes, the editors have full license to change the title ;-) 20:23:40 Hugo: Same position as Marc. Uncomfortable with section 2.1 "EP representatation" Not representation, but definition. Can see this as editorial problem, or mixing representation with definition. 20:23:54 Hugo: Mildly uncomfortable with this. Like having abstract props. 20:23:59 ack Jonathan 20:24:05 ack Marsh 20:24:35 ack anish 20:24:37 Marsh: A couple other items: Don't have to solve 101 or 104 to declare victory. No implementation consequences. Stability of document is important. Can live with status quo. 20:24:56 q+ 20:26:19 q+ Gudge 20:26:37 Anish: Editors have full license with editorial changes. Do think 101 and 104 are important. We have created abstract model, claim extensibility, but don't say how. Don't say how to reverse map infoset to abstract, specifically for EPR. EPR infoset is extensible, but what about abstract model? Not clear what happens. Katy's example is the first I've heard where someone wants to... 20:26:38 ...actually do something with abstract model (but think documenting infoset would be as easy). Don't see reason for having abstract model. Documentation alone is not enough, given 101 and 104. 20:26:47 ack Tom 20:27:00 I note that we've successfully using the (extensible) Infoset abstraction without over-architecting the extensibility model 20:27:07 Tom: I like the proposal. Not do or die. Simplifies by having only one level. Always know where to put text. 20:27:08 ack Gudge 20:28:16 Gudge: Don't think one-way mapping is a problem. Common in specs, e.g. SOAP 1.2 datamodel. We've discussed "how does extensibility work?" It's up to other specs to say how it works. Fond of keeping abstract models; it's cleaner. Pure infoset does not make life better. 20:28:34 MNot: Does anyone feel very strongly about this? 20:28:43 Anish: Have to address extensibility issue. 20:28:48 steve_winkler has joined #ws-addr 20:28:48 MNot: That's 101, right? 20:29:03 Anish: 101 and 104 go hand in hand. 20:29:28 MNot: Of course, but on table now is collapsing. Would solve 101 but there are other ways. Do you feel strongly about this, Anish? 20:29:40 Anish: This is a good way to go. Need to resolve 101 and 104 somehow. 20:29:46 Gudge: What about doing nothing. 20:29:51 Anish: Not happy with that. 20:29:53 q+ 20:30:31 Prasad's proposal: "The information model of an end point reference is extensible in that additional properties and attributes on the properties may be added. See the XML Infoset model section for a formal specification of the extensibility points at the XML Infoset level." 20:30:39 Umit: Prasad sent message today about extensibility. Would need to add something to abstract model per what prasad said, saying that abstract extensibility follows infoset ext. 20:31:17 q+ 20:31:20 Umit: Would this meet Anish's requirement? As AI owner, I was going to propose something much like this, so think Anish's proposal is viable for EPRs. 20:31:21 ack Glen 20:31:52 ack anish 20:31:58 Glen: Prasad's was about what I was going to say. Tells extension writers to update abstract model as well. (except for Must Understand :-) 20:32:02 Let me add though I like collapsing 2.1 and 2.2 better. 20:32:42 Anish: Whole issue is what happens to abstract model? We're handwaving as it is. Can use attribute, any, whatever, with no guidance. 20:32:47 Glen: How else can you do it? 20:32:56 Anish: What is value of abstract model? 20:33:00 MNot: Old argument. 20:33:23 MNot: What do people think of Prasad's proposal? 20:33:27 Umit: Chad? 20:34:13 q+ 20:34:15 MNot: More complex than that. This discussion is to see if group wants to revisit issue. But there is still a lot of doubt. 20:34:45 Umit: We were talking about extensibility of MAPs, not EPRs. MAP extensibility was the big item, not EPR. This is a bit different. 20:34:45 -Jonathan_Marsh 20:35:32 Umit: 101 and 104 is talking about EPR, not MAP. Anish happened to do extra work for MAPs. Doing one and not the other would be inconsistent, but collapsing EPR doesn't reopen MAP issue. 20:36:12 MNot: Not talking about MAPs, but about vote on collapsing out abstract model. If group doesn't have a problem, not a problem. But if there are doubts, we need a higher standard. 20:37:07 Anish: Not trying to raise abstract model issue again. But if we do have one, we need to address extensibility if we want interoperability. Handwaving now. If there is value in abstract model, there is more work to be done. 20:37:14 Mnot: for group to decide. 20:37:51 MNot: Proposals on table (EPRs): Collapse abstract model, or Prasad's proposal to map infoset extensions to abstract model. 20:38:27 Anish: As the proposal stands, properties in abstract model are extensible, see infoset for infoset extensibility, but doesn't address extension to abstract model. 20:38:40 Glen: THink it needs tweaking as well. Not hard. 20:38:56 Umit: If collapse, don't need to do anything. 20:39:03 q? 20:39:09 ack anish 20:39:33 scribe: mnot 20:40:09 -dhull 20:40:38 chad has joined #ws-addr 20:41:06 option 1: colapse abstract model and EPRs 20:41:29 option 2: tweak text make extensibility per extension 20:41:39 option 3: status quo 20:41:54 question: way forward for LC104 20:42:02 chad, question: way forward for LC104 20:42:03 vote: 2, 3, 1 20:42:10 chad, option 1: colapse abstract model and EPRs 20:42:18 chad, option 2: tweak text make extensibility per extension 20:42:28 chad, option 3: status quo 20:42:32 vote: 2, 3, 1 20:42:41 +dhull 20:42:41 vote: 2 20:42:48 vote: 1 20:42:52 vote: 1 20:42:54 vote 2,1 20:42:54 vote: 1 20:42:57 vote 3, 2, 1 20:43:03 vote: 2,1 20:43:03 vote: 2,3 20:43:07 vote 2, 3 20:43:11 +Marsh 20:43:15 vote: 1 20:43:17 vote:3 20:43:29 vote: 2, 3, 1 20:43:36 vote: 2, 3, 1 20:43:43 vote: 3, 1, 2 20:43:43 -Marsh 20:43:44 vote:1,2 20:43:47 vote: 2, 3 20:43:49 vote: 3 20:43:54 scribe: dhull 20:43:54 vote: 3, 2, 1 20:44:00 vote: 3,2,1 20:44:05 vote: 2, 3 20:44:06 vote: gudge: 3, 2 20:44:16 vote: 2, 3, 1 20:44:17 vote: 3, 2 20:44:21 vote: 2, 3 20:44:25 vote: 2, 1, 3 20:44:40 chad, count 20:44:40 Question: way forward for LC104 20:44:40 Option 1: colapse abstract model and EPRs (5) 20:44:40 Option 2: tweak text make extensibility per extension (10) 20:44:40 Option 3: status quo (7) 20:44:40 22 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vinoski (2, 3) 20:44:44 Round 1: Count of first place rankings. 20:44:47 Round 2: Eliminating candidate 1. 20:44:48 Round 3: Eliminating candidate 3. 20:44:48 vote: 3 20:44:50 Candidate 2 is elected. 20:44:53 Winner is option 2 - tweak text make extensibility per extension 20:45:05 chad, count 20:45:05 Question: way forward for LC104 20:45:05 Option 1: colapse abstract model and EPRs (5) 20:45:05 Option 2: tweak text make extensibility per extension (10) 20:45:05 Option 3: status quo (8) 20:45:05 23 voters: abbie (3) , andreas (1) , anish (1) , Arun (2, 3) , bob (3, 2, 1) , dhull (2, 1) , dorchard (1) , GlenD (2, 3, 1) , gudge (3, 2) , hugo (2, 3, 1) , Katy (2, 3) , marc (2, 3) , mlpeel (3, 1, 2) , Nilo (1) , pauld (3, 2) , PaulKnight (3) , prasad (2, 3, 1) , steve_winkler (2, 1, 3) , TomRutt (1, 2) , TonyR (3, 2, 1) , uyalcina (2, 3, 1) , vikas (3) , vinoski (2, 3) 20:45:09 Round 1: Count of first place rankings. 20:45:13 Round 2: Eliminating candidate 1. 20:45:13 Round 3: Eliminating candidate 3. 20:45:15 Candidate 2 is elected. 20:45:17 Winner is option 2 - tweak text make extensibility per extension 20:45:31 chad, details 20:45:59 +Marsh 20:46:47 MNot: will this cover both 101, 104? 20:47:02 Omnes: various 20:47:29 ACTION: Glen to review proposal for LC 101; due EOW 20:47:48 ACTION: Dhull to provide concrete faults writeup. 20:48:01 -Marsh 20:48:14 Anish: Haven't discussed MAPs (but don't expect support for that). 20:48:29 MNot: Does anyone want to speak for the MAP aspect? 20:48:32 (silence) 20:48:55 MNot: LC 101. Can we discuss this now, or wait for Glen's proposal? 20:48:56 -Mark_Little 20:49:16 Glen: Just need to tweak text. Corresponding parts in abstract and infoset descriptions. 20:49:17 +Marsh 20:49:19 Umit: +1 20:49:31 Mnot: Deferring discussion of 101, 104 20:49:43 TOPIC: LC20 20:50:14 Mnot: semantics of anon URI. Dhull made proposal for "return to sender" semantics. Not much discussion yet. 20:50:20 Mnot: Where do we sit? 20:50:33 http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jun/0117 20:51:51 glen: In wsdl, we had a discussion of the breadth of reply; we came up with text. Should we refer to that? 20:52:13 dhull: there's only a paragraph here, let's go over it 20:52:41 -Marsh 20:53:36 +Marsh 20:54:32 tomr: name change may be a problem, but otherwise like it 20:54:38 glen: seems more restrictive than WSDL 20:54:46 glen: restricts it to the underlying transport facilities. 20:54:55 glen: that's OK; wouldn't refer back to wsdl. 20:55:06 q+ 20:55:24 dhull: I think the touchstone is that if the receiver gets anon, would it know what to do? In HTTP, it has a nice, well-defined place to throw the message. 20:56:01 glen: I can imagine a system that replies to a fixed queue, and therefore I don't need something on the wire; in that case you'd use another URI. I like this. 20:56:15 dhull: Right; we'd define other pseudo-URIs. 20:56:19 glen: I like the crisper URIs. 20:56:24 ack tony 20:56:34 Tony: as far as the name goes, I don't like anon; I prefer sender. 20:56:51 I can live with the name change to "sender" 20:57:27 sender could be taken to imply that one should send the reply to the [source] endpoint 20:58:03 and shouldn't that be the same? 20:58:51 Marsh: I have concerns that some semantics are lost; before, it was 'use the underlying layer', now there are some cases taht can't be covered. 20:58:54 so the Source EPR should have a 'sender' address - seems a little recursive 20:59:09 good point 20:59:20 Sender is not the correct word. We need to connote use of an underlying back chanel 20:59:48 dhull: there are two different levels; there's the transport level, and the higher MEP level where I would like anon to mean 'send it right back to me.' 21:00:04 dhull: there might be multiple ways to realise that at the transport level. 21:00:16 dhull: there are differnet meanings, depending on how you look at it. 21:00:17 q+ 21:00:28 dhull: either way is valid; but I'm uncomfortable leaving it open. 21:00:29 +1 to David 21:00:59 dorch: I agree that it's not quite right, but I can't think of anything better. 21:01:05 dorch: I think sender is worse than anon. 21:01:24 dorch: unless somebody can come up with something better; I don't see us doing it anytime soon. 21:01:41 dhull: I think sender is the right way to say send it back to the sender; we probably want to say both. 21:01:58 dorch: I could come up with a protocol that has a back channel that goes somewhere other than the sender. 21:02:16 dhull: in that case, you'd use anon 21:03:03 -Vikas_Deolaliker 21:03:05 dorch: feels like angels on a pin 21:03:22 dhull: no, there are two different meanings being thrown around 21:03:31 q++ 21:03:39 dorch: do we have two words now? 21:03:42 dhull: no 21:03:55 + +1.408.748.aaaa 21:04:29 ack TomR 21:04:32 ack + 21:04:56 q+ 21:06:06 ack dhull 21:06:14 q+ 21:08:27 q- 21:10:11 ACTION: David Hull to revise proposal lc20 21:10:23 scribe: dhull 21:10:35 TOPIC: LC69 21:11:36 If we have two different uri values, we have to decide which is the "default" for reply to, and "to" 21:11:43 Mnot: Jacek's issue: Mandatory reply-to. Reopened I50. Katy has put forth two proposals. 21:11:51 andreas has joined #ws-addr 21:11:55 the binding might specify which is default 21:12:30 Katy: Wrote up proposal for "no reply" URI. Did two proposals because there were two interpretations of proposal. 21:13:45 Katy: Wanted to see it all written down. Suspect that everyone would be happy with one or the other. Does make things more complex. There is a general issue of whether introducing another URI is a good way to go, then discuss particular proposals. Does fix problem, but at expense of complexity. Is there a better way? The two proposals are very similar. No point in discussing them... 21:13:47 ...without disucssing larger issue. 21:14:11 Katy: Do support the proposals. No specific preference. But is there an easier way? 21:15:02 Katy: Maybe attributes? Specifically, would address Paco's concern. 21:15:09 q+ 21:15:30 -Marsh 21:15:53 Glen: Does solve problem. More common use case (and solution) is going to be that "no reply expected" will generally be captured elsewhere. Adding new URI addresses concern, not complicated, but probably won't be used. 21:16:03 MNot: Will this be required if no reply expected? 21:16:07 Glen: I hope not. 21:16:32 MNot: Is "no reply EPR" required if no reply expected? 21:16:58 Katy: Should be fine, I think. 21:17:06 Marc: Default is anonymous. 21:17:11 ack marc 21:17:12 Glen: decided at higher level. 21:17:56 Marc: Question: is meaning "not-valid URI"? Or more like "dev null" (can't send to it, vs.can send to bit-bucket). More comfortable with /dev/null. 21:18:16 Katy: Missed that. Slightly different semantics. 21:18:31 MNot: Very good question. Popping up, is everyone comfortable with general diection. 21:18:48 s/diection/direction/ 21:19:38 Gudge: not required to use it if you don't expect a reply? 21:19:41 Mnot: yes. 21:19:50 Gudge: Why is it useful. 21:19:59 Mnot, Glen: Gets us to CR. 21:20:13 Umit: Gudge has point? What is usage pattern. Recommended? 21:20:22 Tom: Avaialbe for use. 21:20:30 Mnot: Loss of information if default is anonymous. 21:21:09 Glen: Interestingly, doesn't let you default to From:. If you want that, put it in explicitly. 21:21:40 MNot: Jacek and WSDL say that anonymous is common case. Paco doesn't want to lose information with defaulting. 21:21:49 Glen: Could get default to From: anyway. 21:22:09 Mnot: Two subquestions. Which proposal is better, fault vs. /dev/null. 21:22:56 Katy (summarizing): First introduces new URI for "no reply" for [reply endpoint]. Second says more general URI OK for [reply ..] [fault ..][source ..] whatever. 21:23:05 my preference is for general purpose URI (reply and fault) that means > /dev/null 21:23:10 MNot: Reply only or more generic. 21:23:27 Tony: Not a small difference. No fault URI is weird. 21:23:38 I like general uri 21:23:39 Marc: Thus general URI for reply, fault or both. 21:23:47 Tony: What does it do? 21:23:55 Gudge: How can you send with no address. 21:24:00 Marc: By default. 21:24:27 MNot: Allows you to say "drop faults on floor". 21:24:41 Tony: Maybe we need two new URIs (one for fault, one for bit-bucket) 21:24:49 MNot: That's second subissue. 21:25:00 Tom: Faults coming from sender? 3-way handshake? 21:25:08 MNot: Don't think so. 21:25:31 Marc: What is use case for "faulting" URI. 21:26:24 Tony: If you're inside Axis or whatever, if it attempts to send to reply to that's sent to faulting URI, service implementation will get fault/exception. /Dev/null will be silently used. 21:26:34 MNot: Let's go back to first subissue (good point, though). 21:27:09 MNot: Where do we sit on making it generic, or just specific to replies. 21:27:10 usefull to be generic 21:27:12 Marc: Generic 21:27:13 +1 21:27:21 MNot: Specific, anyone? 21:27:44 MNot: Looks like generic "not-valid" URI. Subissue 2: Bit-bucket or faulting behavior? 21:27:53 Mnot: Tony, cases for both versions? 21:28:07 Tony: Prefer having a selection of standard URIs rather than one-size-fits-all. 21:28:19 Marc: What happens if you put faulting URI in fault to? 21:28:27 Tony: Back-channel. 21:28:33 Mnot: There might be cases that don't work. 21:28:42 Katy: Some cases have unconstrained behaviour. 21:28:50 Marc: Effectively the same as /dev/null. 21:28:55 Mnot: Might be useful in reply 21:29:24 TonyR: It's the case of idiot web service, framework is smart and does appropriate thing (e.g., guns web service) 21:29:35 MNot: So proposal is two variant URIs. 21:30:05 Marc: second would say "I don't want replies", first (?) would say "I want fault if someone tries to reply" 21:30:13 Tom: Don' tunderstand that faulting behavior. 21:30:29 Marc: Don't see point of it either. Shouldn't care if someone tried to send a reply, as long as I don't get it. 21:30:38 +Jonathan_Marsh 21:31:06 TonyR: Doesn't make sense with only two parties, but WSs will live in frameworks. 21:31:17 Tom: Don't we already have afaults for unsupported to: address? 21:31:34 MNot: Who thinks faulting version is a good idea. Everyone seems to like /dev/null version. 21:32:16 Tony: Just realised ... Now speaking against my own topic ... If we do have /dev/null, framework can still chastise web service. 21:32:29 Tony: (or its author) 21:32:50 Mnot: Anyone else still interested in faulting version? No. 21:33:12 MNot: Proposal is now "generic not-valid URI, /dev/null semantics". 21:33:19 MNot: (currently faults) 21:33:27 Katy: Correct. Shall I write this up? 21:33:51 MNot: Trying to close the issue right now. Can write this up after the fact. 21:34:00 Mnot: Proposal understood. 21:34:03 Omnes: Silence. 21:34:36 Mark, Are you going to ask about dates for August F2F? 21:34:45 MNot: Would close I50, LC69, LC108. Jonathan, is this OK with WSDL group? 21:34:52 Marsh: THink so. 21:35:21 s/OK/likely to be OK/ 21:35:32 Marc: Captures text to be edited, but needs work. Think not valid is a bad name. Can I change? 21:35:43 Tony: Still like /dev/null. 21:36:17 Mnot: None is better. Give editor license! 21:36:31 I like none better than null 21:36:33 Mnot: Any objections? 21:36:43 Mnot: None. Issue closed. 21:36:51 - +1.408.748.aaaa 21:36:57 Mnot: Thanks Katy for detailed proposal. V. helpful. 21:37:22 TOPIC LC 55, 87 21:37:30