IRC log of ws-addr on 2006-10-23

Timestamps are in UTC.

19:49:52 [RRSAgent]
RRSAgent has joined #ws-addr
19:49:52 [RRSAgent]
logging to
19:50:08 [bob]
zakim, this will be ws_addrws
19:50:08 [Zakim]
I do not see a conference matching that name scheduled near this time, bob
19:50:36 [bob]
zakim, this will be ws_addrwg
19:50:36 [Zakim]
ok, bob; I see WS_AddrWG()4:00PM scheduled to start in 10 minutes
19:51:00 [bob]
Meeting: Web Services Addressing WG Teleconference
19:51:04 [David_Illsley]
David_Illsley has joined #ws-addr
19:51:11 [bob]
Chair: Bob Freund
19:52:17 [TonyR]
TonyR has joined #ws-addr
19:53:14 [Dug]
Dug has joined #ws-addr
19:53:44 [Zakim]
WS_AddrWG()4:00PM has now started
19:53:51 [Zakim]
19:55:46 [Zakim]
19:56:02 [Zakim]
19:56:22 [TonyR]
zakim, ??p4 is me
19:56:22 [Zakim]
+TonyR; got it
19:56:37 [TonyR]
zakim, who is on the phone?
19:56:37 [Zakim]
On the phone I see Doug_Davis, Bob_Freund, TonyR
19:56:41 [Zakim]
+ +44.196.286.aaaa
19:57:06 [bob]
19:57:08 [David_Illsley]
zakim, is me
19:57:08 [Zakim]
+David_Illsley; got it
19:57:48 [Dug]
How do i tell zakim to list me as "Dug" instead of "Doug_Davis" ?
19:58:15 [Zakim]
19:58:25 [Dug]
zakim, Doug_Davis is Dug
19:58:25 [Zakim]
+Dug; got it
19:58:28 [Dug]
cool - thanks!
19:58:38 [pauld]
pauld has joined #ws-addr
19:58:38 [MrGoodner]
MrGoodner has joined #ws-addr
19:58:57 [bob]
zakim, cool - thanks!
19:58:57 [Zakim]
I don't understand 'cool - thanks!', bob
19:59:18 [Zakim]
20:00:25 [Zakim]
20:00:42 [Zakim]
20:00:46 [agupta]
agupta has joined #ws-addr
20:00:48 [gpilz]
gpilz has joined #ws-addr
20:01:05 [Zakim]
20:01:35 [plh]
plh has joined #ws-addr
20:02:00 [prasad]
prasad has joined #ws-addr
20:02:06 [Zakim]
20:02:06 [TRutt_]
TRutt_ has joined #ws-addr
20:02:22 [PaulKnight]
PaulKnight has joined #ws-addr
20:02:38 [Zakim]
20:02:45 [agupta]
zakim, [Sun] is me
20:02:45 [Zakim]
+agupta; got it
20:02:58 [anish]
anish has joined #ws-addr
20:03:13 [plh]
zakim, ??p6 is MarcG
20:03:17 [Zakim]
+MarcG; got it
20:03:35 [Zakim]
20:03:49 [Zakim]
20:04:16 [Zakim]
20:04:39 [bob]
Observer+ Doug Davis (IBM)
20:04:45 [Zakim]
20:04:55 [Paco]
Paco has joined #ws-addr
20:05:35 [Zakim]
20:05:52 [David_Illsley]
zakim, mute me
20:05:52 [Zakim]
David_Illsley should now be muted
20:06:27 [dorchard]
dorchard has joined #ws-addr
20:06:36 [pauld]
zakim, IPcaller contains Katy
20:06:36 [Zakim]
+Katy; got it
20:06:48 [Zakim]
20:06:52 [dhull]
dhull has joined #ws-addr
20:06:58 [Katy]
Katy has joined #ws-addr
20:08:19 [bob]
scribe David Hull
20:08:26 [anish]
Scribe: dhull
20:08:28 [bob]
scribe: David Hull
20:09:16 [dhull]
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 [dhull]
bob: Today's proposal moves in that direction.
20:10:02 [anish]
20:10:11 [dhull]
philippe: Will this slow us down?
20:10:14 [dhull]
bob: Don't know
20:10:55 [dhull]
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 [dhull]
Anish: Can also say that XMLP has been asked for similar effort regarding MTOM
20:11:27 [dhull]
Bob: how about drafting one and throwing it over the fence for review? Or should we work jointly?
20:11:47 [dhull]
Dhull: Prefer throwing it over the fence.
20:12:01 [dhull]
Bob: There being no objection, let's take that tack.
20:12:22 [dhull]
Bob: No addtions to agenda; agenda stands as is.
20:12:32 [anish]
20:12:33 [TRutt_]
20:12:40 [dhull]
Bob: Approval of minutes. Any objections?
20:13:03 [dhull]
Tom: Editorial error in header number in issue number (same in both headers). Is this important?
20:13:20 [dhull]
Bob: Will check before posting. Other issues?
20:13:31 [bob]
ack tru
20:13:38 [dhull]
Bob: I will review minutes then post them.
20:14:06 [dhull]
Bob: AIs (beyond constant plea for more WSDL testers -- speak right up ...)
20:14:10 [dhull]
Omnes: Dead silence
20:14:18 [dhull]
Bob: AI Tony to complete table.
20:15:44 [dhull]
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 [dhull]
Bob: New issues: Wanted to raise possibility of generating primer/FAQ. What do folks think?
20:16:38 [dhull]
Crickets: Chirp, chirp
20:17:07 [dhull]
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 [dhull]
Bob: Who would write it.
20:17:27 [dhull]
Katy: Great idea, but it will be hard to get someone to find time.
20:17:32 [dhull]
MGoodner: WOuld not have time.
20:17:49 [dhull]
Arun: Very good idea. Have blogged about it, but do not have time.
20:17:53 [pauld]
sent my 2p worth to the list:
20:18:03 [gpilz]
I could spend some time on a WS-A primer
20:18:22 [dhull]
Bob: Arun, is there anything you've already done you could contribute?
20:18:29 [dhull]
Arun: Could send it later this week.
20:19:02 [dhull]
Bob: Gil, could you look it over and get scope of effort?
20:19:04 [dhull]
Gil: Yes
20:19:22 [dhull]
Bob: Good. At least want to stop questions to "Guru" about where to send faults.
20:19:51 [dhull]
Bob: Now to the main event, CR33.
20:20:09 [dhull]
Bob: When we left off we were discussing Paco & Anish's proposal.
20:20:42 [Zakim]
20:20:54 [dhull]
Paco: Simple proposal for A6 on our list. Requires no changes to core, just cover anon assertion in WSDL.
20:22:09 [dhull]
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 [dhull]
Paco: We assume backchannel exists and is identifiable for some transports.
20:22:56 [dhull]
Paco: Option 1: Get rid of wsaw:Anonymous and wsaw:UsingAddressing
20:22:59 [yinleng]
yinleng has joined #ws-addr
20:23:25 [dhull]
Paco: Option 2: Keep wsaw:UsingAddressing, default is fully supported, options for other tow possibilities.
20:24:04 [Zakim]
20:24:11 [yinleng]
zakim, ??p19 is me
20:24:11 [Zakim]
+yinleng; got it
20:24:24 [dhull]
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 [dhull]
Bob: We can always talk about names separate from concept. What do people feel about concept.
20:25:08 [dhull]
Pins: Drop noisily
20:25:21 [dhull]
Bob: Does this completely resolve CR33?
20:25:29 [dhull]
Anish: We think so.
20:25:51 [dhull]
Bob: How do we reconcile this with string compare wording in core spec?
20:25:52 [pauld]
zakim, who is noisy?
20:26:01 [dhull]
someone has a speakerphone on
20:26:09 [dhull]
Anish: Looking ...
20:26:09 [Zakim]
pauld, listening for 11 seconds I heard sound from the following: Anish_Karmarkar (16%), [IBM] (42%), DOrchard (25%)
20:26:14 [dhull]
Paco: Need to refresh memory
20:26:15 [bob]
zakim, whi is making noise
20:26:15 [Zakim]
I don't understand 'whi is making noise', bob
20:26:18 [pauld]
zakim, who is noisy?
20:26:26 [Dug]
20:26:33 [Zakim]
pauld, listening for 10 seconds I heard sound from the following: 19 (19%), Bob_Freund (95%), DOrchard (28%)
20:26:40 [anish]
20:27:09 [dhull]
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 [dhull]
Paco: Can't recall anything relevant to stirng compare (?)
20:27:34 [pauld]
zakim, who is noisy?
20:27:42 [bob]
ack dug
20:27:49 [bob]
ack anish
20:27:50 [Zakim]
pauld, listening for 11 seconds I heard sound from the following: Anish_Karmarkar (86%), DOrchard (12%)
20:28:11 [dhull]
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 [dhull]
20:28:30 [dhull]
Anish: THis marker means service has this capability.
20:28:37 [bob]
ack dhull
20:28:42 [dorchard]
zakim, who is noisy?
20:29:00 [Zakim]
dorchard, listening for 10 seconds I heard sound from the following: Bob_Freund (0%), Dave_Hull (90%), DOrchard (28%), Plh (0%)
20:29:05 [bob]
Dhull: not passionately against this proposal, but feels that the ground is a bit slippery
20:29:29 [pauld]
mute, dorchard
20:29:30 [dorchard]
zakim, mute me
20:29:30 [Zakim]
DOrchard should now be muted
20:29:56 [Paco]
20:30:50 [bob]
Dhull: made a proposal to have a way to place information in the address field to mark as to purpose
20:31:10 [bob]
dhull: use regex to recognize the uri
20:31:32 [bob]
20:32:14 [bob]
Dhull: "backchannel" creates a bit of problem of scope
20:32:54 [dhull]
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 [Zakim]
20:33:02 [dhull]
would be nice to have a non-HTTP example
20:33:30 [dhull]
Bob: Would this work for you, Dug?
20:33:53 [anish]
20:34:05 [dhull]
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 [bob]
ack paco
20:34:11 [bob]
ack anish
20:34:40 [bob]
+1 as to scheme attribute
20:35:13 [dhull]
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 [MrGoodner]
20:35:46 [bob]
ack mrg
20:36:10 [dhull]
MGoodner: Wondering if nested assertions were considered. E.g., backchannel as sub-assertion of WSA supported.
20:36:42 [dhull]
Anish: Did consider it. Don't remember details of why we ended up thinking that independent assertions would be better.
20:37:40 [dhull]
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 [dhull]
MGoodner: Not yet, but these seem like further qualifications of WSA supported. But only had time for a quick look.
20:38:37 [dhull]
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 [dhull]
MGoodner: Do policy guidelines talk about whether nesting would be appropriate?
20:39:16 [dhull]
Paco: DOn't know. Separate assertions seemed better.
20:39:37 [dhull]
Bob: Is this general direction something folks are comfortable.
20:39:44 [dhull]
Tony: Can live with it?
20:39:53 [dhull]
?: Option 1 or option 2?
20:39:59 [dhull]
Bob: General direction.
20:40:08 [anish]
20:40:58 [dhull]
Bob: Am I correct in understanding that WSDL marker gives general control, policy can give finer control.
20:41:15 [dhull]
Anish: Thought we were using same tack as before. These can be either WSDL or policy assertions.
20:41:30 [dhull]
Paco: THink people will move to policy, but this allows for grandfathering
20:41:39 [dhull]
Bob: So we mirror in either WSDL or Policy
20:41:41 [dhull]
Anish: Yes
20:41:54 [dhull]
Bob: So given sub-options here, which way do we go?
20:42:13 [dhull]
Bob: (Looking at Paco's most recent email)
20:42:23 [dhull]
Bob: Paco, what do you recommend
20:42:43 [dhull]
Paco: Option 1 is much cleaner. Doesn't split between WSDL and policy. Can still use WSDL markers
20:43:14 [bob]
20:43:14 [anish]
20:43:38 [MrGoodner]
20:43:45 [David_Illsley]
MGoodner, Warning against nesting: Last sentence of
20:43:47 [bob]
ack mrg
20:44:04 [dhull]
MGoodner: Policy assertions only without WSDL markers?
20:44:42 [dhull]
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 [dorchard]
20:44:53 [dorchard]
zakim, unmute me
20:44:53 [Zakim]
DOrchard should no longer be muted
20:45:04 [dhull]
Bob: This would move us back to LC, right?
20:45:20 [dhull]
Philippe: Yes, it would.
20:45:30 [bob]
ack dorc
20:45:41 [dhull]
DaveO: Does this marker appear any place UsingAddressing can be used?
20:45:45 [dhull]
Paco: Yes
20:45:48 [MrGoodner]
20:45:56 [dhull]
DaveO: Effectively, take any place UA is used and put this in
20:46:00 [bob]
ack mrg
20:46:00 [dhull]
Paco: Yes, you can.
20:46:18 [dhull]
MGoodner: What would be impact of using option 2, additively? STill LC?
20:46:41 [dhull]
Bob: You mean adding two add'l WSDL markers?
20:46:46 [dhull]
Mgoodner: Right
20:47:07 [dhull]
MGoodner: Does this change LC
20:47:18 [dhull]
Bob: Design change, not editorial change
20:47:30 [dhull]
MGoodner: E.g., could new elements go into new namespace?
20:47:37 [dhull]
Bob: Maybe. Philippe?
20:47:57 [Katy]
20:48:05 [dhull]
Anish: Remove anon, add two new?
20:48:22 [dhull]
Bob: Proposal is publish what we have, then publish 1.1 with addition in new namespace.
20:48:38 [dhull]
MG: Was proposing keeping existing namespace, new namespace for new elements
20:48:49 [dhull]
Anish: Remove wsaw:anon from existing namespace
20:48:58 [dhull]
MG: DOn't know, just trying to understnd
20:49:16 [dhull]
Anish: Either way ahve to get rid of wsaw:Anon. What would it mean to remove element and keep namespace?
20:49:22 [bob]
ack katy
20:49:54 [dorchard]
q+ to say that removing would be an incompatible change as there would be unexpected behaviour
20:50:20 [pauld]
zakim, mute dorchard
20:50:20 [Zakim]
DOrchard should now be muted
20:50:22 [dhull]
Katy: Before we actually add these, should check for requirement.
20:50:41 [dhull]
Katy: If we remove wsaw:anon, we will have a namespace change as there is interop issue
20:50:49 [bob]
ack dorch
20:50:50 [pauld]
zakim, unmute dorchard
20:50:51 [Zakim]
dorchard, you wanted to say that removing would be an incompatible change as there would be unexpected behaviour
20:50:56 [Zakim]
DOrchard was not muted, pauld
20:51:56 [dhull]
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 [dhull]
Anish: My concern to.
20:52:15 [dhull]
Bob: Seems like breaking change to me. Pub rules would move us back to LC, new namespace.
20:53:02 [plh]
20:53:04 [dhull]
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 [MrGoodner]
20:53:58 [MrGoodner]
20:54:10 [bob]
ack plh
20:54:15 [dhull]
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 [bob]
q+ plh
20:55:10 [dhull]
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 [dhull]
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 [dhull]
Bob: So if we propose it's a non-breaking change, show analysis.
20:56:19 [bob]
ack plh
20:56:20 [dhull]
DaveO: If it's a breaking change, show the break.
20:57:00 [dhull]
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 [bob]
ack mrg
20:57:40 [dhull]
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 [anish]
20:58:26 [dhull]
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 [dhull]
Bob: Not sure
20:58:36 [bob]
ack anish
20:59:30 [dhull]
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 [dhull]
Katy: Could consider removing wsaw:Anon and keeping these markers. Would cause namespace change, but better for long term.
21:00:07 [dhull]
Bob: Feels cleaner to me.
21:01:17 [dhull]
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 [dhull]
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 [MrGoodner]
21:02:35 [dhull]
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 [bob]
ack mrg
21:03:10 [dhull]
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 [dhull]
MG: Also not sure whether it's appropriate to say backchannel without even mentioning anonymous.
21:04:18 [MrGoodner]
21:04:37 [dhull]
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 [bob]
ack mrg
21:05:24 [dhull]
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 [Dug]
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 [Dug]
21:05:39 [dhull]
Bob: P & A, are you willing to take this further.
21:05:59 [dhull]
Anish: Need to talk about what kind of wordings we want, and the sort of analysis that DaveO mentioned.
21:06:14 [gpilz]
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 [Dug]
"as defined by the transport" or something like that - but mentioning specific URIs doesn't address the issue
21:07:21 [dhull]
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 [Dug]
(I should say "mentioning" and "limiting the URIs")
21:07:55 [gpilz]
21:07:56 [David_Illsley]
gpilz, I'm not sure I agree, surely a client knows what backchannels are available to it?
21:08:18 [dhull]
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 [bob]
ack gil
21:08:28 [dhull]
(so who says if some other URI is backchannel?)
21:08:39 [bob]
ack gp
21:09:18 [dhull]
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 [dhull]
Paco: This is a per binding/transport thing. You need to define a lot of things with a binding anywya.
21:09:58 [dhull]
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 [anish]
21:10:07 [dhull]
Paco: IF you're using the URI you know what it means.
21:10:15 [dhull]
Gil: I know what it menas, but not if it will be accepted.
21:10:32 [dhull]
Paco: You know it means use the backchannel, and you know if that's OK. YOu have enough information.
21:10:38 [bob]
ack ani
21:10:42 [Dug]
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 [dhull]
Anish: If you want that level of precision, then you may want option A8, which changes core, or DaveH's proposal.
21:11:05 [gpilz]
dug - that's an idea
21:11:09 [dhull]
Isn't RMAnon independent of transport?
21:11:31 [gpilz]
21:11:31 [dhull]
Anish: Want to leave core alone and leave what backchannel means to the binding.
21:11:40 [dhull]
Bob: Meta-backchannel. Whatever it means to you.
21:11:51 [David_Illsley]
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 [dhull]
(missed something)
21:12:21 [bob]
ack gpil
21:12:27 [Dug]
david_I - true
21:12:37 [MrGoodner]
21:12:52 [dhull]
Gil: Inclined toward this approach of skirting the issue of what qualifies or not, but does it introduce interop problems?
21:13:11 [Dug]
leave WSA simple and extensible
21:13:28 [dhull]
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 [bob]
ack mrg
21:13:44 [Paco]
21:13:57 [Dug]
does the core spec already say Anon == backchannel?
21:14:36 [bob]
ack paco
21:14:38 [dhull]
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 [MrGoodner]
21:16:25 [dhull]
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 [dhull]
...or give assertions that have behavior behind them. WE give assertions.
21:16:34 [Dug]
21:16:40 [bob]
ack mrg
21:17:22 [dhull]
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 [bob]
ack dug
21:18:18 [MrGoodner]
21:18:23 [gpilz]
+1 to dug
21:18:46 [bob]
ack mrg
21:18:53 [dhull]
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 [dhull]
...what backchannel means.
21:19:27 [dhull]
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 [dhull]
Dug: Not a hard requirement, but couldn't hurt, whether or not new special URI are anonymous in nature.
21:20:06 [dhull]
MG: So how does none apply in this discussion of backchannel.
21:20:11 [dhull]
Dug: It doesn't.
21:21:03 [MrGoodner]
Are we back to wsaw:Anonymous again?
21:21:16 [dhull]
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 [dhull]
Bob: Sounds like primer material.
21:21:52 [dhull]
Bob: Any more that we can fruiitfully hash out without going into next level of detail?
21:22:16 [dhull]
Bob: A&P have next step to do. Do we want to keep option 2 on table?
21:22:38 [dhull]
MG: Yes. Especially w.r.t. analyzing for breaking change
21:22:46 [dhull]
Bob: Are you amenable?
21:23:04 [dhull]
Bob: i.e. to keeping Option 2 on the table for analysis.
21:23:13 [dhull]
Paco: THink that's fair.
21:23:20 [dhull]
Anish: Fine with it.
21:23:56 [dhull]
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 [dhull]
Bob: So we are done with CR33 discussion for today.
21:24:52 [dhull]
Bob: Or were any of the other options more attactive?
21:25:01 [dhull]
Omnes: Nada
21:25:29 [dhull]
Bob: AOB?
21:26:37 [dhull]
Paco: When do we need to do this?
21:27:05 [dhull]
Bob: Should have proposal out no later than Wed or Thu, otherwise call on 30 October would be a waste.
21:27:16 [dhull]
Paco: Happy to send this out by then.
21:27:28 [dhull]
MG: Should we give RX TC more time and come back in 2 weeks?
21:28:40 [dhull]
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 [dhull]
Paco: Will have it out by Thu.
21:28:59 [dhull]
Bob: Next call October 30.
21:29:15 [dhull]
Tony: I have uploaded modified table for CR31, so we can discuss that.
21:29:22 [dhull]
Bob: CR33 will impact the table
21:29:25 [dhull]
Tony: THought it might.
21:29:47 [dhull]
Bob: Adjourned
21:29:47 [Zakim]
21:29:49 [Zakim]
21:29:49 [Zakim]
21:29:51 [Zakim]
21:29:52 [Zakim]
21:29:54 [Zakim]
21:29:55 [Zakim]
21:29:56 [Zakim]
21:29:57 [Zakim]
21:29:58 [Zakim]
21:30:00 [Zakim]
21:30:05 [Zakim]
21:30:06 [Zakim]
21:30:08 [agupta]
agupta has left #ws-addr
21:30:08 [Zakim]
21:30:09 [Zakim]
21:30:13 [Zakim]
21:31:53 [TonyR]
TonyR has left #ws-addr
21:32:01 [yinleng]
yinleng has left #ws-addr
21:32:31 [Zakim]
21:32:49 [bob]
rrsagent, make logs public
21:33:25 [bob]
rrsagent, generate minutes
21:33:25 [RRSAgent]
I have made the request to generate bob
21:35:09 [bob]
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]
Dug has left #ws-addr
21:35:45 [bob]
action: arun to publish what he has to the group as a starting point (possibly) for a primer
21:35:58 [bob]
rrsagent, generate minutes
21:35:58 [RRSAgent]
I have made the request to generate bob
21:38:23 [TRutt_]
TRutt_ has left #ws-addr
21:38:44 [bob]
action: bob to describe this general direction to the RX TC on the Thursday teleconference
21:38:52 [bob]
rrsagent, generate minutes
21:38:52 [RRSAgent]
I have made the request to generate bob
21:39:22 [bob]
scribenick: dhull
21:39:31 [bob]
rrsagent, henerate minutes
21:39:31 [RRSAgent]
I'm logging. I don't understand 'henerate minutes', bob. Try /msg RRSAgent help
21:39:41 [bob]
rrsagent, generate minutes
21:39:41 [RRSAgent]
I have made the request to generate bob
21:44:36 [bob]
bob has left #ws-addr
22:05:01 [Zakim]
disconnecting the lone participant, Paul_Downey, in WS_AddrWG()4:00PM
22:05:02 [Zakim]
WS_AddrWG()4:00PM has ended
22:05:06 [Zakim]
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 [Zakim]
... Prasad_Yendluri, [IBM], Katy, Dave_Hull, DOrchard, yinleng
23:41:29 [Zakim]
Zakim has left #ws-addr