IRC log of ws-addr on 2005-07-11

Timestamps are in UTC.

19:41:45 [RRSAgent]
RRSAgent has joined #ws-addr
19:41:45 [RRSAgent]
logging to
19:41:55 [mnot]
zakim, this will be ws_addrw
19:41:55 [Zakim]
ok, mnot; I see WS_AddrWG()4:00PM scheduled to start in 19 minutes
19:42:07 [mnot]
Meeting: Web Services Addressing Teleconference
19:42:11 [mnot]
Chair: Mark Nottingham
19:42:53 [mnot]
19:49:44 [mlpeel]
mlpeel has joined #ws-addr
19:53:54 [Katy]
Katy has joined #ws-addr
19:54:52 [Marsh]
Marsh has joined #ws-addr
19:55:03 [TonyR]
TonyR has joined #ws-addr
19:57:06 [Nilo]
Nilo has joined #ws-addr
19:57:34 [Zakim]
WS_AddrWG()4:00PM has now started
19:57:40 [Zakim]
19:58:01 [PaulKnight]
PaulKnight has joined #ws-addr
19:58:05 [bob]
bob has joined #ws-addr
19:58:09 [Zakim]
19:58:49 [Zakim]
19:59:16 [Zakim]
19:59:33 [Zakim]
19:59:52 [TonyR]
zakim, ??p4 is me
19:59:52 [Zakim]
+TonyR; got it
20:00:26 [Zakim]
20:00:27 [Zakim]
20:01:09 [Zakim]
20:01:15 [TomRutt]
TomRutt has joined #ws-addr
20:01:17 [Zakim]
20:01:24 [prasad]
prasad has joined #ws-addr
20:01:26 [Zakim]
20:01:39 [Zakim]
20:01:55 [Zakim]
20:02:03 [Zakim]
20:02:04 [Zakim]
20:02:07 [pauld]
pauld has joined #ws-addr
20:02:16 [Zakim]
20:02:17 [Zakim]
20:02:18 [Zakim]
20:02:23 [Zakim]
20:02:31 [dhull]
dhull has joined #ws-addr
20:02:31 [Zakim]
20:03:02 [Zakim]
20:03:03 [Zakim]
20:03:04 [Zakim]
20:03:21 [uyalcina]
uyalcina has joined #ws-addr
20:03:53 [steve_winkler]
steve_winkler has joined #ws-addr
20:04:18 [Zakim]
20:04:20 [Arun]
Arun has joined #ws-addr
20:04:22 [anish]
anish has joined #ws-addr
20:04:49 [Zakim]
20:05:00 [Zakim]
20:05:07 [Zakim]
20:05:15 [marc]
marc has joined #ws-addr
20:05:17 [Arun]
zakim, [Sun] is me
20:05:17 [Zakim]
+Arun; got it
20:05:20 [Zakim]
20:06:31 [dhull]
scribe: dhull
20:06:45 [Zakim]
20:07:05 [vinoski]
vinoski has joined #ws-addr
20:07:20 [dhull]
march: Status update.
20:07:34 [dhull]
(after AIs)
20:08:18 [dhull]
Corrections of minutes?
20:08:39 [dhull]
Minutes approved (no objection)
20:09:44 [dhull]
AIs: Anish, Umit done. DHull LC76: Needs to be more concrete. Due 15 July.
20:10:18 [dhull]
AI: LC107 (Marsh). Draft, not mailed yet. Editorial issue will be resolved. Marked as done.
20:10:33 [dhull]
AI: LC68 (marsh) Done.
20:11:14 [dhull]
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]
steve_winkler has joined #ws-addr
20:11:50 [dhull]
20:11:52 [vikas]
vikas has joined #ws-addr
20:12:08 [dhull]
Anish has made proposal, discussion is active.
20:12:25 [mnot]
zakim, who is making noise?
20:12:31 [dhull]
Anish: Made draft of spec with abstract model of EPR.
20:12:35 [Zakim]
20:12:36 [Zakim]
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]
GlenD has joined #ws-addr
20:13:22 [andreas]
andreas has joined #ws-addr
20:13:47 [dhull]
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 [dhull]
MNot: Two related issues. Getting rid of abstract model for EPRs, and for MAPs.
20:14:16 [Zakim]
20:14:22 [dhull]
Marsh: Only object to MAP part.
20:14:41 [dhull]
Anish: Issue is only about EPR, but did MAP too to see what it would look like.
20:15:20 [uyalcina]
20:15:54 [dhull]
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 [marc]
20:16:22 [dhull]
Marsh: Anish has shown that collapsing will work. Bummer is that it's no longer consistent with MAP description.
20:16:36 [dhull]
Marsh: Not against getting rid of EPR section.
20:16:57 [dhull]
Mnot: Prasad, would you be OK with separating out EPR part, dropping abstract model in EPRs.
20:17:17 [dhull]
Prasad: No problem with that.
20:17:30 [Zakim]
20:17:49 [dhull]
Prasad: Some editorial inconsistencies to be taken care of. No objection to collapsing.
20:17:53 [dhull]
Anish: Where?
20:17:57 [dhull]
Prasad: Section 2.1
20:18:04 [dhull]
Mnot: So some editorial work.
20:18:23 [dhull]
Prasad: [address] in metadata, for example.
20:18:37 [dhull]
(missed much of the detail there)
20:18:44 [mnot]
20:18:55 [Marsh]
20:19:02 [mnot]
ack uyal
20:19:44 [mnot]
zakim, who is on the phone?
20:19:44 [Zakim]
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 [Zakim]
... 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 [Katy]
20:20:18 [dhull]
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]
uyalcina has joined #ws-addr
20:20:32 [dhull]
MNot: Anyone against EPR changes?
20:20:54 [dhull]
Paco?: Have some concerns about how it's written.
20:21:01 [dorchard]
dorchard has joined #ws-addr
20:21:05 [mnot]
20:21:14 [dhull]
Katy: There are some advantages to abstract model, esp. for documenting. but not against collapsing.
20:21:18 [mnot]
ack marc
20:21:19 [uyalcina]
uyalcina has joined #ws-addr
20:21:27 [anish]
20:21:28 [Katy]
20:22:44 [dhull]
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 [mnot]
ack hugo
20:23:35 [anish]
yes, the editors have full license to change the title ;-)
20:23:40 [dhull]
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 [dhull]
Hugo: Mildly uncomfortable with this. Like having abstract props.
20:23:59 [mnot]
ack Jonathan
20:24:05 [mnot]
ack Marsh
20:24:35 [mnot]
ack anish
20:24:37 [dhull]
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 [TomRutt]
20:26:19 [Marsh]
q+ Gudge
20:26:37 [dhull]
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 [dhull]
...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 [mnot]
ack Tom
20:27:00 [Marsh]
I note that we've successfully using the (extensible) Infoset abstraction without over-architecting the extensibility model
20:27:07 [dhull]
Tom: I like the proposal. Not do or die. Simplifies by having only one level. Always know where to put text.
20:27:08 [mnot]
ack Gudge
20:28:16 [dhull]
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 [dhull]
MNot: Does anyone feel very strongly about this?
20:28:43 [dhull]
Anish: Have to address extensibility issue.
20:28:48 [steve_winkler]
steve_winkler has joined #ws-addr
20:28:48 [dhull]
MNot: That's 101, right?
20:29:03 [dhull]
Anish: 101 and 104 go hand in hand.
20:29:28 [dhull]
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 [dhull]
Anish: This is a good way to go. Need to resolve 101 and 104 somehow.
20:29:46 [dhull]
Gudge: What about doing nothing.
20:29:51 [dhull]
Anish: Not happy with that.
20:29:53 [GlenD]
20:30:31 [mnot]
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 [dhull]
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 [anish]
20:31:20 [dhull]
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 [mnot]
ack Glen
20:31:52 [mnot]
ack anish
20:31:58 [dhull]
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 [uyalcina]
Let me add though I like collapsing 2.1 and 2.2 better.
20:32:42 [dhull]
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 [dhull]
Glen: How else can you do it?
20:32:56 [dhull]
Anish: What is value of abstract model?
20:33:00 [dhull]
MNot: Old argument.
20:33:23 [dhull]
MNot: What do people think of Prasad's proposal?
20:33:27 [dhull]
Umit: Chad?
20:34:13 [anish]
20:34:15 [dhull]
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 [dhull]
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 [Zakim]
20:35:32 [dhull]
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 [dhull]
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 [dhull]
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 [dhull]
Mnot: for group to decide.
20:37:51 [dhull]
MNot: Proposals on table (EPRs): Collapse abstract model, or Prasad's proposal to map infoset extensions to abstract model.
20:38:27 [dhull]
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 [dhull]
Glen: THink it needs tweaking as well. Not hard.
20:38:56 [dhull]
Umit: If collapse, don't need to do anything.
20:39:03 [mnot]
20:39:09 [mnot]
ack anish
20:39:33 [mnot]
scribe: mnot
20:40:09 [Zakim]
20:40:38 [chad]
chad has joined #ws-addr
20:41:06 [pauld]
option 1: colapse abstract model and EPRs
20:41:29 [pauld]
option 2: tweak text make extensibility per extension
20:41:39 [pauld]
option 3: status quo
20:41:54 [pauld]
question: way forward for LC104
20:42:02 [pauld]
chad, question: way forward for LC104
20:42:03 [GlenD]
vote: 2, 3, 1
20:42:10 [pauld]
chad, option 1: colapse abstract model and EPRs
20:42:18 [pauld]
chad, option 2: tweak text make extensibility per extension
20:42:28 [pauld]
chad, option 3: status quo
20:42:32 [GlenD]
vote: 2, 3, 1
20:42:41 [Zakim]
20:42:41 [anish]
vote: 2
20:42:48 [anish]
vote: 1
20:42:52 [Nilo]
vote: 1
20:42:54 [dhull]
vote 2,1
20:42:54 [dorchard]
vote: 1
20:42:57 [TonyR]
vote 3, 2, 1
20:43:03 [dhull]
vote: 2,1
20:43:03 [marc]
vote: 2,3
20:43:07 [Katy]
vote 2, 3
20:43:11 [Zakim]
20:43:15 [andreas]
vote: 1
20:43:17 [PaulKnight]
20:43:29 [hugo]
vote: 2, 3, 1
20:43:36 [prasad]
vote: 2, 3, 1
20:43:43 [mlpeel]
vote: 3, 1, 2
20:43:43 [Zakim]
20:43:44 [TomRutt]
20:43:47 [Katy]
vote: 2, 3
20:43:49 [abbie]
vote: 3
20:43:54 [dhull]
scribe: dhull
20:43:54 [TonyR]
vote: 3, 2, 1
20:44:00 [bob]
vote: 3,2,1
20:44:05 [vinoski]
vote: 2, 3
20:44:06 [anish]
vote: gudge: 3, 2
20:44:16 [uyalcina]
vote: 2, 3, 1
20:44:17 [pauld]
vote: 3, 2
20:44:21 [Arun]
vote: 2, 3
20:44:25 [steve_winkler]
vote: 2, 1, 3
20:44:40 [pauld]
chad, count
20:44:40 [chad]
Question: way forward for LC104
20:44:40 [chad]
Option 1: colapse abstract model and EPRs (5)
20:44:40 [chad]
Option 2: tweak text make extensibility per extension (10)
20:44:40 [chad]
Option 3: status quo (7)
20:44:40 [chad]
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 [chad]
Round 1: Count of first place rankings.
20:44:47 [chad]
Round 2: Eliminating candidate 1.
20:44:48 [chad]
Round 3: Eliminating candidate 3.
20:44:48 [vikas]
vote: 3
20:44:50 [chad]
Candidate 2 is elected.
20:44:53 [chad]
Winner is option 2 - tweak text make extensibility per extension
20:45:05 [pauld]
chad, count
20:45:05 [chad]
Question: way forward for LC104
20:45:05 [chad]
Option 1: colapse abstract model and EPRs (5)
20:45:05 [chad]
Option 2: tweak text make extensibility per extension (10)
20:45:05 [chad]
Option 3: status quo (8)
20:45:05 [chad]
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 [chad]
Round 1: Count of first place rankings.
20:45:13 [chad]
Round 2: Eliminating candidate 1.
20:45:13 [chad]
Round 3: Eliminating candidate 3.
20:45:15 [chad]
Candidate 2 is elected.
20:45:17 [chad]
Winner is option 2 - tweak text make extensibility per extension
20:45:31 [TonyR]
chad, details
20:45:59 [Zakim]
20:46:47 [dhull]
MNot: will this cover both 101, 104?
20:47:02 [dhull]
Omnes: various
20:47:29 [mnot]
ACTION: Glen to review proposal for LC 101; due EOW
20:47:48 [dhull]
ACTION: Dhull to provide concrete faults writeup.
20:48:01 [Zakim]
20:48:14 [dhull]
Anish: Haven't discussed MAPs (but don't expect support for that).
20:48:29 [dhull]
MNot: Does anyone want to speak for the MAP aspect?
20:48:32 [dhull]
20:48:55 [dhull]
MNot: LC 101. Can we discuss this now, or wait for Glen's proposal?
20:48:56 [Zakim]
20:49:16 [dhull]
Glen: Just need to tweak text. Corresponding parts in abstract and infoset descriptions.
20:49:17 [Zakim]
20:49:19 [dhull]
Umit: +1
20:49:31 [dhull]
Mnot: Deferring discussion of 101, 104
20:49:43 [dhull]
20:50:14 [dhull]
Mnot: semantics of anon URI. Dhull made proposal for "return to sender" semantics. Not much discussion yet.
20:50:20 [dhull]
Mnot: Where do we sit?
20:50:33 [mnot]
20:51:51 [mnot]
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 [mnot]
dhull: there's only a paragraph here, let's go over it
20:52:41 [Zakim]
20:53:36 [Zakim]
20:54:32 [mnot]
tomr: name change may be a problem, but otherwise like it
20:54:38 [mnot]
glen: seems more restrictive than WSDL
20:54:46 [mnot]
glen: restricts it to the underlying transport facilities.
20:54:55 [mnot]
glen: that's OK; wouldn't refer back to wsdl.
20:55:06 [TonyR]
20:55:24 [mnot]
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 [mnot]
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 [mnot]
dhull: Right; we'd define other pseudo-URIs.
20:56:19 [mnot]
glen: I like the crisper URIs.
20:56:24 [mnot]
ack tony
20:56:34 [mnot]
Tony: as far as the name goes, I don't like anon; I prefer sender.
20:56:51 [TomRutt]
I can live with the name change to "sender"
20:57:27 [marc]
sender could be taken to imply that one should send the reply to the [source] endpoint
20:58:03 [TonyR]
and shouldn't that be the same?
20:58:51 [mnot]
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 [marc]
so the Source EPR should have a 'sender' address - seems a little recursive
20:59:09 [TonyR]
good point
20:59:20 [TomRutt]
Sender is not the correct word. We need to connote use of an underlying back chanel
20:59:48 [mnot]
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 [mnot]
dhull: there might be multiple ways to realise that at the transport level.
21:00:16 [mnot]
dhull: there are differnet meanings, depending on how you look at it.
21:00:17 [TomRutt]
21:00:28 [mnot]
dhull: either way is valid; but I'm uncomfortable leaving it open.
21:00:29 [GlenD]
+1 to David
21:00:59 [mnot]
dorch: I agree that it's not quite right, but I can't think of anything better.
21:01:05 [mnot]
dorch: I think sender is worse than anon.
21:01:24 [mnot]
dorch: unless somebody can come up with something better; I don't see us doing it anytime soon.
21:01:41 [mnot]
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 [mnot]
dorch: I could come up with a protocol that has a back channel that goes somewhere other than the sender.
21:02:16 [mnot]
dhull: in that case, you'd use anon
21:03:03 [Zakim]
21:03:05 [mnot]
dorch: feels like angels on a pin
21:03:22 [mnot]
dhull: no, there are two different meanings being thrown around
21:03:31 [TomRutt]
21:03:39 [mnot]
dorch: do we have two words now?
21:03:42 [mnot]
dhull: no
21:03:55 [Zakim]
+ +1.408.748.aaaa
21:04:29 [mnot]
ack TomR
21:04:32 [mnot]
ack +
21:04:56 [dhull]
21:06:06 [mnot]
ack dhull
21:06:14 [steve_winkler]
21:08:27 [steve_winkler]
21:10:11 [mnot]
ACTION: David Hull to revise proposal lc20
21:10:23 [dhull]
scribe: dhull
21:10:35 [dhull]
21:11:36 [TomRutt]
If we have two different uri values, we have to decide which is the "default" for reply to, and "to"
21:11:43 [dhull]
Mnot: Jacek's issue: Mandatory reply-to. Reopened I50. Katy has put forth two proposals.
21:11:51 [andreas]
andreas has joined #ws-addr
21:11:55 [TonyR]
the binding might specify which is default
21:12:30 [dhull]
Katy: Wrote up proposal for "no reply" URI. Did two proposals because there were two interpretations of proposal.
21:13:45 [dhull]
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 [dhull]
...without disucssing larger issue.
21:14:11 [dhull]
Katy: Do support the proposals. No specific preference. But is there an easier way?
21:15:02 [dhull]
Katy: Maybe attributes? Specifically, would address Paco's concern.
21:15:09 [marc]
21:15:30 [Zakim]
21:15:53 [dhull]
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 [dhull]
MNot: Will this be required if no reply expected?
21:16:07 [dhull]
Glen: I hope not.
21:16:32 [dhull]
MNot: Is "no reply EPR" required if no reply expected?
21:16:58 [dhull]
Katy: Should be fine, I think.
21:17:06 [dhull]
Marc: Default is anonymous.
21:17:11 [mnot]
ack marc
21:17:12 [dhull]
Glen: decided at higher level.
21:17:56 [dhull]
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 [dhull]
Katy: Missed that. Slightly different semantics.
21:18:31 [dhull]
MNot: Very good question. Popping up, is everyone comfortable with general diection.
21:18:48 [pauld]
21:19:38 [dhull]
Gudge: not required to use it if you don't expect a reply?
21:19:41 [dhull]
Mnot: yes.
21:19:50 [dhull]
Gudge: Why is it useful.
21:19:59 [dhull]
Mnot, Glen: Gets us to CR.
21:20:13 [dhull]
Umit: Gudge has point? What is usage pattern. Recommended?
21:20:22 [dhull]
Tom: Avaialbe for use.
21:20:30 [dhull]
Mnot: Loss of information if default is anonymous.
21:21:09 [dhull]
Glen: Interestingly, doesn't let you default to From:. If you want that, put it in explicitly.
21:21:40 [dhull]
MNot: Jacek and WSDL say that anonymous is common case. Paco doesn't want to lose information with defaulting.
21:21:49 [dhull]
Glen: Could get default to From: anyway.
21:22:09 [dhull]
Mnot: Two subquestions. Which proposal is better, fault vs. /dev/null.
21:22:56 [dhull]
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 [marc]
my preference is for general purpose URI (reply and fault) that means > /dev/null
21:23:10 [dhull]
MNot: Reply only or more generic.
21:23:27 [dhull]
Tony: Not a small difference. No fault URI is weird.
21:23:38 [TomRutt]
I like general uri
21:23:39 [dhull]
Marc: Thus general URI for reply, fault or both.
21:23:47 [dhull]
Tony: What does it do?
21:23:55 [dhull]
Gudge: How can you send with no address.
21:24:00 [dhull]
Marc: By default.
21:24:27 [dhull]
MNot: Allows you to say "drop faults on floor".
21:24:41 [dhull]
Tony: Maybe we need two new URIs (one for fault, one for bit-bucket)
21:24:49 [dhull]
MNot: That's second subissue.
21:25:00 [dhull]
Tom: Faults coming from sender? 3-way handshake?
21:25:08 [dhull]
MNot: Don't think so.
21:25:31 [dhull]
Marc: What is use case for "faulting" URI.
21:26:24 [dhull]
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 [dhull]
MNot: Let's go back to first subissue (good point, though).
21:27:09 [dhull]
MNot: Where do we sit on making it generic, or just specific to replies.
21:27:10 [TomRutt]
usefull to be generic
21:27:12 [dhull]
Marc: Generic
21:27:13 [dhull]
21:27:21 [dhull]
MNot: Specific, anyone?
21:27:44 [dhull]
MNot: Looks like generic "not-valid" URI. Subissue 2: Bit-bucket or faulting behavior?
21:27:53 [dhull]
Mnot: Tony, cases for both versions?
21:28:07 [dhull]
Tony: Prefer having a selection of standard URIs rather than one-size-fits-all.
21:28:19 [dhull]
Marc: What happens if you put faulting URI in fault to?
21:28:27 [dhull]
Tony: Back-channel.
21:28:33 [dhull]
Mnot: There might be cases that don't work.
21:28:42 [dhull]
Katy: Some cases have unconstrained behaviour.
21:28:50 [dhull]
Marc: Effectively the same as /dev/null.
21:28:55 [dhull]
Mnot: Might be useful in reply
21:29:24 [dhull]
TonyR: It's the case of idiot web service, framework is smart and does appropriate thing (e.g., guns web service)
21:29:35 [dhull]
MNot: So proposal is two variant URIs.
21:30:05 [dhull]
Marc: second would say "I don't want replies", first (?) would say "I want fault if someone tries to reply"
21:30:13 [dhull]
Tom: Don' tunderstand that faulting behavior.
21:30:29 [dhull]
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 [Zakim]
21:31:06 [dhull]
TonyR: Doesn't make sense with only two parties, but WSs will live in frameworks.
21:31:17 [dhull]
Tom: Don't we already have afaults for unsupported to: address?
21:31:34 [dhull]
MNot: Who thinks faulting version is a good idea. Everyone seems to like /dev/null version.
21:32:16 [dhull]
Tony: Just realised ... Now speaking against my own topic ... If we do have /dev/null, framework can still chastise web service.
21:32:29 [dhull]
Tony: (or its author)
21:32:50 [dhull]
Mnot: Anyone else still interested in faulting version? No.
21:33:12 [dhull]
MNot: Proposal is now "generic not-valid URI, /dev/null semantics".
21:33:19 [dhull]
MNot: (currently faults)
21:33:27 [dhull]
Katy: Correct. Shall I write this up?
21:33:51 [dhull]
MNot: Trying to close the issue right now. Can write this up after the fact.
21:34:00 [dhull]
Mnot: Proposal understood.
21:34:03 [dhull]
Omnes: Silence.
21:34:36 [steve_winkler]
Mark, Are you going to ask about dates for August F2F?
21:34:45 [dhull]
MNot: Would close I50, LC69, LC108. Jonathan, is this OK with WSDL group?
21:34:52 [dhull]
Marsh: THink so.
21:35:21 [Marsh]
s/OK/likely to be OK/
21:35:32 [dhull]
Marc: Captures text to be edited, but needs work. Think not valid is a bad name. Can I change?
21:35:43 [dhull]
Tony: Still like /dev/null.
21:36:17 [dhull]
Mnot: None is better. Give editor license!
21:36:31 [TomRutt]
I like none better than null
21:36:33 [dhull]
Mnot: Any objections?
21:36:43 [dhull]
Mnot: None. Issue closed.
21:36:51 [Zakim]
- +1.408.748.aaaa
21:36:57 [dhull]
Mnot: Thanks Katy for detailed proposal. V. helpful.
21:37:22 [dhull]
TOPIC LC 55, 87
21:37:30 [dhull]
TOPIC: LC 55, 87
21:38:25 [dhull]
Marc: Two buckets of comments. Tweaks and nits, e.g., used property not in EPR, meant one in EPR. Significant discussion around whether section should be normative.
21:39:19 [dhull]
Marc: Idea was to specify mechanism that SHOULD but not MUST be implemented. If in use, this is how you should garner trust. Pushback: Two sentences is not nearly enough. Shouldn't specify anything, just give example. A couple of +1s to that.
21:40:02 [anish]
21:40:05 [dhull]
MNot: This is re-opening an issue. Had had shoo-in to re-open and close with this. Is that still the case or is there controversy. Can those who opposed normativity speak to this?
21:40:22 [mnot]
ack anish
21:40:42 [dhull]
Anish: Clarification: Normative if you choose to use it, right?
21:40:48 [dhull]
MNot: Does it require testing?
21:41:04 [mnot]
ack hugo
21:42:50 [dhull]
Hugo: Marc summarized accurately. Basic security model is an improvement on status quo. May need minor tweaks. Spoke with security experts at W3C. They were worried that it was underspecified. E.g., talks about domain comparison, several ways to do this in X509. Need to hammer out deatils for interop. Two sentences is far from what we need for that. A lot of effort/expertise...
21:42:51 [dhull]
...required, maybe more than we have in this WG. If we recommend a mechanism, need to test that it works.
21:43:13 [dhull]
Hugo: Introducing significant new text, so back to working draft.
21:44:04 [dhull]
MNot: This discussion is re-opening an issue. Can we incorporate this proposal quickly and easily? Are we comfortable? Talk about it now or next week?
21:44:33 [dhull]
Marc: Clarification: Considering whole of text, or parts? Can we accept as-is and discuss taking normative bit out?
21:44:52 [dhull]
MNot: Don't think we can do that. Could get into nasty situation about normativity.
21:45:02 [dhull]
MNot: Hugo -- is non-normative version OK?
21:45:19 [dhull]
Hugo: As example, won't impact CR, will improve model.
21:45:34 [dhull]
MNot: Others?
21:45:42 [dhull]
Omnes: nada
21:45:52 [Zakim]
21:45:53 [dhull]
21:46:05 [dhull]
Marc: Would prefer not to make normative section example.
21:46:57 [dhull]
MNot: Intention for F2F is to ask if people are for or against re-opening. We'll see what group decides. If we can't come to consensus, suppose we won't re-open. Will have discussion F2F.
21:47:28 [dhull]
21:48:05 [dhull]
MNot: Proposal just needs to be more concrete. Get crackin'
21:49:24 [dhull]
MNot: Plan going forward. Very few LC issues on SOAP and Core. Rest seem to have clear way forward. Will look at expanded faults, maybe adjust. LC 5 is utility of source. LC 69 Jacek responded with possible modification. A few more ends to tie up. Hope to close rest of LC issues on Monday.
21:50:43 [dhull]
MNot: Then need to do other things to get into CR. Implementation and testing schedules, PR entrance criteria. Want to have docs ready for CR at or near end of F2F. Come ready to vote. Will be worried if we can't get out of LC by end of last meeting. If so, break for meetings in August.
21:51:24 [dhull]
MNot: Then back into WSDL doc, depending on timing. May be able to leave F2F early instead. Start on WSDL in September. Still need host.
21:52:30 [dhull]
MNot: Will provide dates soon. Probably last half of week of 5 Sept. Or maybe week preceding.
21:52:39 [dhull]
Marsh: WSDL wanted week of 12th.
21:52:57 [dhull]
MNot: Won't be able to do that, won't need to co-locate.
21:53:04 [vinoski]
vinoski has left #ws-addr
21:53:08 [Zakim]
21:53:18 [bob]
bob has left #ws-addr
21:53:21 [Zakim]
21:53:23 [Zakim]
21:53:24 [Zakim]
21:53:24 [Zakim]
21:53:25 [Zakim]
21:53:26 [Zakim]
21:53:27 [Zakim]
21:53:28 [Zakim]
21:53:29 [Zakim]
21:53:30 [Zakim]
21:53:32 [Zakim]
21:53:34 [Zakim]
21:53:35 [TonyR]
TonyR has left #ws-addr
21:53:36 [Zakim]
21:53:38 [Zakim]
21:53:40 [Zakim]
21:53:42 [Zakim]
21:53:44 [Zakim]
21:53:46 [Zakim]
21:53:48 [Zakim]
21:53:50 [Zakim]
21:53:52 [Zakim]
21:53:56 [PaulKnight]
PaulKnight has left #ws-addr
21:54:04 [Zakim]
21:55:40 [mnot]
rrsagent, attendees
21:55:40 [RRSAgent]
I'm logging. I don't understand 'attendees', mnot. Try /msg RRSAgent help
21:55:50 [mnot]
rrsagent, make log public
21:55:58 [mnot]
rrsagent, generate minutes
21:55:58 [RRSAgent]
I have made the request to generate mnot
22:05:00 [Zakim]
disconnecting the lone participant, Arun, in WS_AddrWG()4:00PM
22:05:02 [Zakim]
WS_AddrWG()4:00PM has ended
22:05:05 [Zakim]
Attendees were Mark_Peel, Mark_Peel/Katy_Warr, Bob_Freund, Nilo_Mitra, TonyR, Andreas_Bjarlestam, MarkN, Hugo, Paul_Knight, Abbie_Barbir, Umit_Yalcinalp, Jonathan_Marsh,
22:05:09 [Zakim]
... Pete_Wenzel, Gudge, dhull, Tom_Rutt, Prasad_Yendluri, Paul_Downey, Anish, Marc_Hadley, Arun, DOrchard, Vikas_Deolaliker, GlenD, Mark_Little, Marsh, +1.408.748.aaaa
22:23:11 [TomRutt]
TomRutt has left #ws-addr
22:32:50 [abbie]
abbie has left #ws-addr