Web Services Addressing -- 4 Dec 2006

<plh> Previous minutes: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Nov/att-0083/27-ws-addr-minutes.html

<bob> meeting: WS-Addressing Working Group Teleconference

<bob> chair: Old Stuffy

<David_Illsley> thanks bob

<bob> scribe: gill

<scribe> scribe: gil

<inserted> scribenick: gpilz

review of minutes

RESOLUTION: minutes accepted

review of agenda

bob: a couple of new issues
... Jonathan noted capitalization probs
... David Illsley's comment on namespaces

DavidI: not sure if my namespace comment needs a new issue

RESOLUTION: close new issue on capitalization with Jonathan's proposal

review action items

bob: Paul Knight sent his review to the mailing list a couple of minutes ago
... people should read and review and be prepared to discuss this on next weeks call

Paul: I'd be happy to discuss at this point . . .

Bob: given the late arrival, let's postpone for next meeting

RESOLUTION: discuss Paul's comments next meeting

CR33

<bob> scribe: bob

Gil: I wrote what I understood to be out agreement based on the lsat call
... specifically we didn't want the absence of the assertion to be its negation since that would lead to the cr33 trap
... a number of points made on the list have called into question some of what I thought we had alredy decided

Anish: I thought that the agreement ws to make the assertions both policy and wsdl markers

Gil: We had decided against that in the prior concall.
... wsdl would be a course grain marker, but policy would fine tune them

Anish: I was explicitly pushing that the new assertions be usable both in wsdl and policy

<TonyR> c/coarse grain/coarse grain/

Gil: Does not make sense to discuss anon / nonanon unless addressing is already inficated as supported
... WS-Policy is pretty mechanical. it would need domain specific smarts

<inserted> scribenick: gpilz

MarcG: my recollection matches what Gil said

<bob> scribe: gil

MarcG: I don't dispute the notion of using matching assertions
... The new proposal nests the Anon/NonAnon under UsingAddressing
... I'm having a hard time with how we would use UsingAddressing both as a WSDL marker and a policy assertion if you can nest Anon/NonAnon underneath
... I thought we had agreed to leave UsingAddressing alone

Bob: so your point is that you don't think the WSDL marker and the policy assertion can have the same QName?

MarcG: It's okay as long as UsingAddressing is a simple policy assertion
... but when you start nesting other policy assertions beneath it, I can't see it

DavidI: I haven't thought that through

Glen: It shouldn't be a problem

Anish: There are two issues: do we want to provide the same capabilities in both WSDL extensions and Policy
... and do we want to nest assertions
... my understanding is that we were going to provide all the capabilities as both WSDL extensions and in WS-Policy
... Gil, I don't see the use case

Gil: server advertises "NonAnonymousResponses" client looks for "UsingAddressing" . . they don't intersect

Katy: Anish, two sub-issues of your first issue
... providing UsingAddressing functionality in WSDL
... and providing "AnonymousResponses" functionality in WSDL
... the group determined that nobody needed "Anon" functionality in WSDL

Anish: the idea was that existing impls that don't understand the new WS-Policy assertions need "anon" in WSDL

Katy: concerned because we asked if anyone needed anon in WSDL and everyone said they didn't

Anish: we certainly need an "anon" marker in WSDL

Katy: as long as someone needs it and someone will implement it, we should include it
... but it makes the spec a lot more complicated

Anish: You think UsingAddressing is complicated?

Katy: No, its not but the "anon" and "nonAnon" markers make things a lot more complicated

Anish: I think it doesn't.

DavidI: There are two different ways of looking at these separate assertions.
... if we have "AnonSupported" as implying "UsingAddressing", but this breaks the intersection rules

<anish> btw, i don't care as much about whether it is a nested assertion or not, i care more about allowing it to be used in WSDL

DavidI: if we have separate assertions so "AnonSupported" doesn't imply "UsingAddressin" you end up with combinations that are invalid
... these invalid alternatives require domain-specific knowledge to detect and exclude

Phillpe: Katy commented that if one person needs something we have to do it. I don't agree.

Bob: Who needs "AnonResponses" in WSDL? Just Anish or anyone else ?

Bob: Anish can you make the case that "AnonResponse" is generally useful as a WSDL extension?

Anish: I thought I did.
... It will take a while for people to get on the WS-Policy band-wagon
... Its simpler to add support for a WSDL extension
... That it is to make everyone to go to WS-Policy to learn abou Anon/NonAnon

Phillpe: Can we do a quick straw-poll?

Bob: <asks for anynone else who thinks AnonResponses need to be a WSDL extension>

Bob: <asks counter-question>

<GlenD> ah, blessed apathy :)

RESULTS: 1 need, 5 don't need (no), 1 maybe

<Zakim> plh, you wanted to try to answer the charter question

<plh> "use of Web Services Addressing components in WSDL 1.1 and WSDL 2.0 message exchange patterns and providing the mechanisms for defining Web Services Addressing property values in WSDL 1.1 and WSDL 2.0 service descriptions"

Philippe: DavidH's question is a good one. Depending upon how you read the charter it could be construed that we need to do it in both places.

Anish: The charter talks about WSDL and not WS-Policy. It seems odd to discuss things that have nothing to do with WSDL in the "WSDL Binding Document"

Bob: We have an open issue to discuss the title of the document.

Anish: Our charter doesn't talk about WS-Policy at all.
... Some people talked about the complexity. Whichever way we go (nested or not) making the assertions dual-purpose won't complicate anything.
... I'm willing to put together a proposal to show people how to use any assertions in both WSDL and WS-Policy

Bob: I was beginning to hope that we were making progress. I don't want to derail that progress. I would like to proceed along the lines
... of doing solely policy assertions then revisit the WSDL extension issue once we get those hammered out.
... Would that be acceptable?

Katy: I'm against the idea of trying to express "AnonResponses" and "NonAnonresponses" in WSDL
... If we do it in both places we have the problem of what to do when the WSDL and Policy disagree
... sticking to just UsingAddressing minimizes the potential for disagreements

Anish: Is anyone suggesting getting rid of dual-use for UsingAddressing?

Bob & Katy: No

Anish: The problems of WSDL and Policy disagreeing are already there for UsingAddressing (cites example)
... Those conflicts need to be resolved in any case so its no big deal to apply those solutions to AnonymousResponses and NonAnonymousResponses

Katy: Yeah same pattern, but more work in each case.
... Fine, if we need both. But I don't think we need both.
... A lot of extra processing for something that nobody seems to need very much.

Bob: Our straw poll (if turned into a formal vote) shows abstain ruling, followed by 'no'
... We could settle this and move forward by a formal vote.
... On the other hand, we could just defer this discussion until we figure out how to express what we want using WS-Policy
... I disagree that the shortest path is to try and address the WSDL extension issue now.

Katy: OK

Bob: I note that Chris Ferris has thrown a log on the fire with regards to wsdl:required="true"

<Zakim> gpilz, you wanted to discuss Chris' point

DavidO: some people are objecting to the description of UsingAddressing based on what is need by the WS-Policy intersection rules
... Some people say we can't have WS-Addr specific policy handling. I'm not sure if I agree with that.
... WS-Policy is in last call and WS-Addr seems to have a fairly simple use of WS-Policy. If we need WS-Policy to do something different we should tell them now.
... Its interesting that one of the first WG's to use WS-Policy is having such problems.

MarcG: If there are issues found with WS-Policy we should let them know.
... I think the problems with the intersection algorithm are overblown. We should just focus on the assertions that we need.
... WS-SX has a large set of complex assertions and they don't seem to be having problems.

Tom: With nested assertions we don't have problems with the intersection algorithm. I agree with ChrisF . . .

Bob: Want to get back to prior call. Someone made a statement that nesting policy assertions is just too complicated. Has that changed?

Tom: We were also talking about nesting parameters which is pretty complicated.

MarcG: I was on the previous calls. I agree that nesting policy assertions is not that hard.
... Though I question using "UsingAddressing" as the top-level container.

Bob: Are people ok with using UsingAddressing as a container and putting AnonResponses and NonAnonResponses as child policies?

Tony: The reason that we split UsingAddressing (the WSDL marker) and AddressingRequired (the policy assertion) was because of this split in semantics

(scribe lost audio(

<bob> scribe: bob

Anish: use framework attribute to define required or optional

TonyR: That won't work because there would be different meanings in different environments

Anish: It is a question of what is the default, the defaults may be different, but the semantics are the same

<dorchard> +1 to TonyR's points.

TonyR: If the defaults are different then they have different meanings

<scribe> scribe: gpilz

DavidI: When I think about this stuff, I try to think about it in WS-Policy-normal form (no "optional")
... If we don't have text saying that the normal form means something different, it doesn't.

Anish: Are you saying that "wsp:optional=true" means that the non-missing case means that addressing is required?

DavidI: Yes.

Bob: Do we have specific changes to Gil's proposal that we would like to make?

Marc: What about David's proposal on Friday?

Bob: Those are commments against Gil's

MarcG: But it changed nesting?

Bob: True

Gil: But I think Bob wants to see a proposal with David's changes to Gil's proposal.

Bob: Right
... Do folks agree that this is the direction we want to go in?

Tony: I remain concerned with one thing about the nesting.
... If the outer container can't have "wsp:optional=true" how do you get the inner assertions to support the required ???

Paco: The point is that "optional" applies to the whole thing

Tony: How can you express that you want an inner assertion but not an outer assertion.

Gil: How/why would I say "I support non-anonymous responses" without saying "I support WS-Addr"?

Bob: Do we agree on the direction?

MarcG: I want to know if we are going to make UsingAddressing act as a container.

DavidI: Let's rename the UsingAddressing policy assertiong to AddressingRequired

MarcG: I would like that.

Anish: Would that be a replacement for UsingAdressing or in addition to?

DavidI: That would be a point for further disucssion.

Bob: I think the point is to distinguish the policy assertion from the WSDL marker.

Anish: So "UsingAddressing" is a WSDL marker and "AddressingRequired" is a policy assertion?

Bob: Yes

MarcG: I think we whould leave "UsingAddressing" alone.

Bob: Leave "UsingAddressing" alone as a WSDL marker.

MarcG: I thought we had agreed to leave UsingAddressing completely alone.

Bob: I thought we were.

MarcG: No, right now you can use UsingAddressing as a policy assertion.

Anish: How can we have both a UsingAddressing policy assertion and a AddressingRequired policy assertion?
... They compete and one is a superset of the other (provides examples)

MarcG: I'd like to see how this develops. But when you start doing nested assertions you have to express that assertion (it can't be defaulted).
... That is, if UsingAddressing has child assertions, you have to express the values of those assertions, you can't leave it empty.
... Whereas, today, you could have a policy with UsingAddressing and no child elements.
... There are implemenations that currently rely on the use of UsingAddressing as a policy assertion.

Tony: I'm reluctant to be bound to someone's early implementation of a draft spec. They knew the risks when they did this.
... We don't have to be bound by their decisions.

Bob: Let's figure out what we need to do then figure out how to minimize impact on existing implementations.

MarcG: I agree with Bob. We can't radically change the marker and keep the same namespace. There are implemations out there the use the current namespace.

<plh> "This namespace URI will be updated only if changes are made to

<plh> the document are significant and impact the implementation of the

<plh> specifications.This namespace URI will be updated only if changes are made to

<plh> the document are significant and impact the implementation of the

<plh> specifications."

<plh> http://www.w3.org/2006/05/addressing/wsdl/

Tony: I'm sorry, but we were still in draft stage.

(someone): We promised that we would change the namespace if we changed the semantics?

Bob: DavidI agree to take an AI to update the current proposal to include nested assertions.

DavidI: Yes.

<scribe> ACTION: ITEM to David Illsley to update Gil's proposal to nest AnonResponse/NonAnonResponses [recorded in http://www.w3.org/2006/12/04-ws-addr-minutes.html#action01]

Name of the "WSDL Binding Document"

Tony: What about "WSDL Binding and Related Matters"?

Bob: "WSDL Binding, Anti-Poverty, and Peace Document"

Anish: Have we ruled out a separate document?

Bob: Phillpe do you have a position on that?

Phillipe: No

Bob: If there are conflicts between WSDL and POlicy it would be handy to have them together.

Anish: If they are not dual-use there is no conflict.

Tony: One could say one thing and one could say another.

Tony & Anish: (back and forth on possible conflicts between WSDL markers and Policy assertions)

Bob: We are well overdue on our mandatory heartbeat requirement. We need to publish a new version soon. Any addition of WS-Policy stuff needs
... a corresponding change to the title.

<anish> Q that i was going to ask: for those supporting no support in WSDL for anon, why would we have a dual use UsingAddressing for WSDL. I.e. won't the same reasoning apply to make UsingAddressing single use (ws-p only)?

Bob: We can decide to split the doc once we have figured out the content

Gil: New name should best be figured out on the mailing list

Bob: True

Anish: If everything is dual-use then it should all be in the same doc

<dorchard> Description Document

Anish: Separate use would seem to require separate documents.

<dorchard> Metadata Document

Bob: WS-Addressing Metadata Document
... I'd like to get to a heartbeat document very shortly.

<dorchard> I take full credit for the brilliant suggestion.

Bob: I'm hopeful we'll have a section on WS-Policy assertions to add on next weeks call.

WS-Policy review

Bob: If people in this group has a set of comments it might be helpful to combine those comments as a group response.
... There are only three calls between now and the end of the review period for WS-Policy
... Would like to make sure we can do what we need using WS-Policy and I would like to do that in parallel with the review period for WS-Polcy.

MarcG: The WS-Policy primer has examples that show the use of the UsingAddressing assertion. Good place to start . . .

Tony: You are suggesting that if we change UsingAddressing, they might not be happy?

MarcG: No.

Anish: Is the Primer in last call?

(all): No

Bob: But we should look at the Primer as a good place to start.

MarcG: I put the link in IRC

Bob: For next weeks call we have the review of Paul Kight's AI, a review of the propsal from David Illsley.

ADJORNED

Web Services Addressing
4 Dec 2006

Attendees

Contents

review of minutes

review of agenda

review action items

CR33

Name of the "WSDL Binding Document"

WS-Policy review

Summary of Action Items

Scribe.perl diagnostic output

Web Services Addressing 4 Dec 2006

Attendees

Contents

review of minutes

review of agenda

review action items

CR33

Name of the "WSDL Binding Document"

WS-Policy review

Summary of Action Items

Scribe.perl diagnostic output

Web Services Addressing
4 Dec 2006