Web Services Addressing WG Teleconference

 

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
... Today's proposal moves in that direction.

philippe: Will this slow us down?

bob: Don't know

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.
... Can also say that XMLP has been asked for similar effort regarding MTOM

Bob: how about drafting one and throwing it over the fence for review? Or should we work jointly?

Dhull: Prefer throwing it over the fence.

Bob: There being no objection, let's take that tack.
... No addtions to agenda; agenda stands as is.
... Approval of minutes. Any objections?

Tom: Editorial error in header number in issue number (same in both headers). Is this important?

Bob: Will check before posting. Other issues?
... I will review minutes then post them.
... AIs (beyond constant plea for more WSDL testers -- speak right up ...)

Omnes: Dead silence

Bob: AI Tony to complete table.

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.

Bob: New issues: Wanted to raise possibility of generating primer/FAQ. What do folks think?

Crickets: Chirp, chirp

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.

Bob: Who would write it.

Katy: Great idea, but it will be hard to get someone to find time.

MGoodner: WOuld not have time.

Arun: Very good idea. Have blogged about it, but do not have time.

<pauld> sent my 2p worth to the list: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0011.html

<gpilz> I could spend some time on a WS-A primer

Bob: Arun, is there anything you've already done you could contribute?

Arun: Could send it later this week.

Bob: Gil, could you look it over and get scope of effort?

Gil: Yes

Bob: Good. At least want to stop questions to "Guru" about where to send faults.
... Now to the main event, CR33.
... When we left off we were discussing Paco & Anish's proposal.

Paco: Simple proposal for A6 on our list. Requires no changes to core, just cover anon assertion in WSDL.
... 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.
... We assume backchannel exists and is identifiable for some transports.
... Option 1: Get rid of wsaw:Anonymous and wsaw:UsingAddressing
... Option 2: Keep wsaw:UsingAddressing, default is fully supported, options for other tow possibilities.

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.

Bob: We can always talk about names separate from concept. What do people feel about concept.

Pins: Drop noisily

Bob: Does this completely resolve CR33?

Anish: We think so.

Bob: How do we reconcile this with string compare wording in core spec?

someone has a speakerphone on

Anish: Looking ...

Paco: Need to refresh memory

Dug: THink the string compare is orthogonal issue. Paco's proposal just says "however you determine it, this tells you whether you can".

Paco: Can't recall anything relevant to stirng compare (?)

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.
... THis marker means service has this capability.

<bob> Dhull: not passionately against this proposal, but feels that the ground is a bit slippery

<pauld> mute, dorchard

<bob> Dhull: made a proposal to have a way to place information in the address field to mark as to purpose

<bob> dhull: use regex to recognize the uri

<bob> Dhull: "backchannel" creates a bit of problem of scope

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.

would be nice to have a non-HTTP example

Bob: Would this work for you, Dug?

Dug: Looks like either would work. Not sure about David's, need to grok it. Would probably work. Leaning toward Paco's

<bob> +1 as to scheme attribute

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.

MGoodner: Wondering if nested assertions were considered. E.g., backchannel as sub-assertion of WSA supported.

Anish: Did consider it. Don't remember details of why we ended up thinking that independent assertions would be better.

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?

MGoodner: Not yet, but these seem like further qualifications of WSA supported. But only had time for a quick look.

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).

MGoodner: Do policy guidelines talk about whether nesting would be appropriate?

Paco: DOn't know. Separate assertions seemed better.

Bob: Is this general direction something folks are comfortable.

Tony: Can live with it?

?: Option 1 or option 2?

Bob: General direction.

<anish> s/\?/Dug/

Bob: Am I correct in understanding that WSDL marker gives general control, policy can give finer control.

Anish: Thought we were using same tack as before. These can be either WSDL or policy assertions.

Paco: THink people will move to policy, but this allows for grandfathering

Bob: So we mirror in either WSDL or Policy

Anish: Yes

Bob: So given sub-options here, which way do we go?
... (Looking at Paco's most recent email)
... Paco, what do you recommend

Paco: Option 1 is much cleaner. Doesn't split between WSDL and policy. Can still use WSDL markers

<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0094.html

<anish> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0094.html

<David_Illsley> MGoodner, Warning against nesting: Last sentence of http://www.w3.org/TR/2006/WD-ws-policy-20060927/#rPolicy_Assertion

MGoodner: Policy assertions only without WSDL markers?

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.

Bob: This would move us back to LC, right?

Philippe: Yes, it would.

DaveO: Does this marker appear any place UsingAddressing can be used?

Paco: Yes

DaveO: Effectively, take any place UA is used and put this in

Paco: Yes, you can.

MGoodner: What would be impact of using option 2, additively? STill LC?

Bob: You mean adding two add'l WSDL markers?

Mgoodner: Right
... Does this change LC

Bob: Design change, not editorial change

MGoodner: E.g., could new elements go into new namespace?

Bob: Maybe. Philippe?

Anish: Remove anon, add two new?

Bob: Proposal is publish what we have, then publish 1.1 with addition in new namespace.

MG: Was proposing keeping existing namespace, new namespace for new elements

Anish: Remove wsaw:anon from existing namespace

MG: DOn't know, just trying to understnd

Anish: Either way ahve to get rid of wsaw:Anon. What would it mean to remove element and keep namespace?

Katy: Before we actually add these, should check for requirement.
... If we remove wsaw:anon, we will have a namespace change as there is interop issue

<Zakim> dorchard, you wanted to say that removing would be an incompatible change as there would be unexpected behaviour

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)

Anish: My concern to.

Bob: Seems like breaking change to me. Pub rules would move us back to LC, new namespace.

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.
... 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.

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?

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.

Bob: So if we propose it's a non-breaking change, show analysis.

DaveO: If it's a breaking change, show the break.

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.

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.
... 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.

Bob: Not sure

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.

Katy: Could consider removing wsaw:Anon and keeping these markers. Would cause namespace change, but better for long term.

Bob: Feels cleaner to me.

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.

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.
... 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.

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.
... Also not sure whether it's appropriate to say backchannel without even mentioning anonymous.

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.

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.

<Dug> if the URI is mentioned as an example then its ok but if its mentioned as the only URI then CR33 is not resolved.

Bob: P & A, are you willing to take this further.

Anish: Need to talk about what kind of wordings we want, and the sort of analysis that DaveO mentioned.

<gpilz> you need to say somthing about what qualifies as "a backchannel" or you are just opening up a whole universe of interop problems

<Dug> "as defined by the transport" or something like that - but mentioning specific URIs doesn't address the issue

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.

<Dug> (I should say "mentioning" and "limiting the URIs")

<David_Illsley> gpilz, I'm not sure I agree, surely a client knows what backchannels are available to it?

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.

(so who says if some other URI is backchannel?)

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.

Paco: This is a per binding/transport thing. You need to define a lot of things with a binding anywya.

Gil: But if I'm using WSA anon I know what's up. But if I have some other URI, how do I know?

Paco: IF you're using the URI you know what it means.

Gil: I know what it menas, but not if it will be accepted.

Paco: You know it means use the backchannel, and you know if that's OK. YOu have enough information.

<Dug> Gil - wouldn't that be an RM issue? let RM define a policy assertion that says whether or not RManonURI is supported

Anish: If you want that level of precision, then you may want option A8, which changes core, or DaveH's proposal.

<gpilz> dug - that's an idea

Isn't RMAnon independent of transport?

Anish: Want to leave core alone and leave what backchannel means to the binding.

Bob: Meta-backchannel. Whatever it means to you.

<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

(missed something)

<Dug> david_I - true

Gil: Inclined toward this approach of skirting the issue of what qualifies or not, but does it introduce interop problems?

<Dug> leave WSA simple and extensible

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.

<Dug> does the core spec already say Anon == backchannel?

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.

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,...
... or give assertions that have behavior behind them. WE give assertions.

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.

<gpilz> +1 to dug

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...
... what backchannel means.

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.

Dug: Not a hard requirement, but couldn't hurt, whether or not new special URI are anonymous in nature.

MG: So how does none apply in this discussion of backchannel.

Dug: It doesn't.

<MrGoodner> Are we back to wsaw:Anonymous again?

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.
... Sounds like primer material.
... Any more that we can fruiitfully hash out without going into next level of detail?
... Anish & Paco have next step to do. Do we want to keep option 2 on table?

MG: Yes. Especially w.r.t. analyzing for breaking change

Bob: Are you amenable?
... i.e. to keeping Option 2 on the table for analysis.

Paco: Think that's fair.

Anish: Fine with it.
... Would like to say that this analysis would be useful independent of backchannel issue, particularly since request was from WSP WG.

Bob: So we are done with CR33 discussion for today.
... Or were any of the other options more attactive?

Omnes: Nada

Bob: AOB?

Paco: When do we need to do this?

Bob: Should have proposal out no later than Wed or Thu, otherwise call on 30 October would be a waste.

Paco: Happy to send this out by then.

MG: Should we give RX TC more time and come back in 2 weeks?

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.

Paco: Will have it out by Thu.

Bob: Next call October 30.

Tony: I have uploaded modified table for CR31, so we can discuss that.

Bob: CR33 will impact the table

Tony: Thought it might.

Bob: Adjourned

<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 [recorded in http://www.w3.org/2006/10/23-ws-addr-minutes.html#action01]

<bob> ACTION: arun to publish what he has to the group as a starting point (possibly) for a primer [recorded in http://www.w3.org/2006/10/23-ws-addr-minutes.html#action02]

<bob> ACTION: bob to describe this general direction to the RX TC on the Thursday teleconference [recorded in http://www.w3.org/2006/10/23-ws-addr-minutes.html#action03]