WS-Addressing WG Teleconference

<scribe> chair: Today's meeting will take non-zero time

<scribe> chair: 23 April minutes accepted without objection

<scribe> chair: New issues --

<scribe> chair: 1) Need for new namespace; we had held namespaces steady from CR to end. In this case we bounced from LC to WD, so new document should get new namespace.

<scribe> chair: Philippe suggested new namespace on CR. Is it necessary to change on LC/CR transition if there is no substantive change?

Philippe: We have control over our namespace. No need to change. Should hold steady until CR. Last time we changed a lot until CR.

<scribe> Chair: Any objection to using dated namespace of next LC for this document?

<Ram> http://www.w3.org/ns/addressing/metadata/

Rama: Suggest short form (in IRC)

<scribe> chair: requires director review

philippe: easily done

Anish: Chances of change after CR much lower. Would rather not assign this (permanent) NS to a WD. If we assign it now and there are changes, then we have to change the NS to something new.

permanent NS should at least have a version

Philippe: Now is our chance to use the short form (as WSDL and others?)

Anish: Did they do that at CR? Having a stable NS is a good goal. Wary of doing it now.

Plh: So we should adopt short form at CR?

Anish: yes

Ram: Want to freeze NS for interop testing. Stable NS helps that.

<scribe> Chair: (jumping ahead) both IBM and MSFT intend to do WSP interop testing soon.

Anish: Nice from interop and impl standpoint, but comparing against risk changes will occur. Less risky to change a dated NS to a shorter version.
... Would rather assign such a name at CR. Is this draft LC or CR?

Plh: LC

<scribe> Chair: Team rep -- what are the rules for the short NS? How many degrees of freedom do we have on keeping it throughout doc lifetime?

plh: Don't need director approval for dated NS. Changes automatically. But then have to remember exact date to use right namespace. Who remembers NS for WSA? So director approved /NS with group deciding anything after that. Approval is lightweight now.

<anish> what happens if the short NS needs to change?

plh: WSP decided to use short version at ns. There's always a risk, even at CR. Here we are doing a new LC so likelihood of change should be small. Companies most concerned are those doing interop anyway.

TRutt: We kept assertion names. Wasn't that to avoid NS change? Do we need NS change for non-syntactic, semantic changes?

Anish: Yes

TRutt: maybe we should change the names then

<scribe> chair: Don't want to change names just to change names

Trutt: Wanted to clarify whether semantic change requires NS change

Plh: yes

Anish: Want to maximize chance short NS survives. LC isn't for interop anyway, that's CR, so that's when we should freeze.

<scribe> chair: May I ask IBM and MSFT, who will do interop, if new dated NS for next LC draft, and then short NS on CR (if WSP is stable), be acceptable?

Ram: The question is what NS to use for interop. This is why we want to freeze.
... Good chance we're going to CR in three weeks.

<scribe> Chair: No problem personally with dated NS

<TRutt__> +1 with anish - keep dated namepace for now

<scribe> Chair: And there is no shortage of them

+1 with Anish, Tom

<scribe> Chair: Don't think optics of short NS is important. Fine with picking new dated NS, and even sticking with it if there are no substantive changes. Thoughts?

Ram: That's a fine position, approach. I would prefer shorter NS but other option is fine as well.

<scribe> Chair: Is it kosher to define a NS alias

<anish> +1

<Ram> http://lists.w3.org/Archives/Public/public-ws-addressing/2007May/0031.html

RESOLUTION: Effective next publication as LC, we will use a May 2007 namespace and hold it constant absent breaking changes

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

Ram: Useful to add change policy to namespace section? Makes expectations clear to reader.

+1 to making expectations clear in general

Anish: This would go in document you get by dereferencing NS?

Ram: Yes

plh: Skeptical of examples of breaking changes. These are all schema changes. Adding complex types, e.g., would not break

<scribe> Chair: Amend proposal to use only text between URI: and "accordingly."

Ram: Just examples, not exhaustive set.

<anish> dhull: we might want to tone down 'uri will not change with each subsequent revision'

<scribe> Chair: would prefer that WG retain control over what is a breaking change

<anish> dhull: suggestion that we accept the principle and then on the ML work on wordings

Katy: How about remove "arbitrarily"?

<scribe> Chair: Seconded

plh: Need to change a bit more. Need to make clearer we don't intend to change from the next LC document.

<bob> URI will not change with each subsequent revision of the corresponding XML Schema documents as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a CR or PR draft, results in non-backwardly compatible changes from a previously published CR or PR draft of the specification, the namespace URI will

<Ram> +1

<bob> URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a LC, CR or PR draft, results in non-backwardly compatible changes from a previously published LC, CR or PR draft of the specification, the

Why not just strike "with each subsequent revision of the corresponding XML Schema documents", leaving URI will not change as the specifications transition through...

<anish> dhull: delete stuff about xml schema

<scribe> Chair: So how about ...

<bob> URI will not change as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a LC, CR or PR draft, results in non-backwardly compatible changes from a previously published LC, CR or PR draft of the specification, the namespace URI will be changed accordingly.

Katy: Do we even need this? No one wants to make changes?

<Ram> +1

Plh: This is for the world at large. Very useful to make guarantees.

RESOLUTION: Text above (modulo grammar) accepted as useful addition to our NS document.

<scribe> Chair: Ram, have your issues been adequately addressed?

<Ram> http://lists.w3.org/Archives/Public/public-ws-addressing/2007May/0026.html

Ram: Yes, but there is one more

<anish> +1

<scribe> Chair: The issue is the referenced version of WSP, now that it is in CR. They have a nice-n-shiny new NS. Shall we update to refer to it?

<scribe> Chair: No objection

RESOLUTION: Update doc to reference current WS-Policy short namespace

<scribe> Chair: Any other new issues? Hearing none ...

<scribe> Chair: LC36 use cases with Tom and Dave

<TRutt__> First example shows intersection of two policies, each with two alternatives, one in common.

<TRutt__> Pa

<TRutt__> Addressing non-anon with Jabber

<TRutt__> Addressing non-anon with http

<TRutt__> Pb

<TRutt__> Addressing non anon with mail

<TRutt__> Addressing non-anon with Jabber

<TRutt__> Intersection yields

<anish> i have an issue that I have not sent in. but it is an ed. issue and should not block us from making progress

<TRutt__> Addressing non-anon with Jabber (a)

<TRutt__> Addressing non-anon with Jabber (b)

TRutt: Some discussion of whether these are client and server or something else. Shouldn't matter.
... Intersection works in this case. Significant that you're pulling in separate parameters (maybe significant)

<TRutt__> Example 2 tries to introduce other response transport options than jabber, http or mail

<TRutt__> Pc

<TRutt__> Addressing non-anon (no restriction)

<TRutt__> Addressing non-anon with Jabber

<TRutt__> Addressing non-anon with http

TRutt: Would rather not discuss exactly what is being intersected. Believe intersection algorithm works here.

<TRutt__> Pd

<TRutt__> Addressing non-anon (no restriction)

<TRutt__> Addressing non-anon with mail

<TRutt__> Addressing non-anon with Jabber

<TRutt__> Intersection yields:

<TRutt__> Addressing non-anon (no restriction) (c)

<TRutt__> Addressing non-anon (no restriction) (d)

<TRutt__> Addresiing non-anon with Jabber (c)

<TRutt__> Addressing non-anon with Jabber (d)

TRutt: Second example addresses optionality. WSP optionality is a bit dangerous, but if you put ever alternative you can deal with in, intersection can handle it.
... Defined separate namespace wts with two fictitions assertions for this example. Don't actually exist.
... Second example end up with two jabbers
... Know from result that HTTP non-anon will work

<bob> ach dhull

Dhull: How do I know HTTP is OK

<bob> Trutt: You know http works, jabber will work, other things may work

<bob> dhull: Do you agree that we have lost information?

<bob> dhull: Policy is not suited for making intelligent domain dependent decisions

<bob> ... what the intersection alg. can do is to compare assertions that exist on both sides

<bob> ... All intersection is doing is pulling together two sources of information

<bob> ... if we can use a better division of labor between policy and addr, that would be preferable.

<bob> trutt: dhull is reading too much into what policy can do

<bob> .. the example is trivial, but is intended to be illustrative

<bob> ... all the intersection does is demonstrate agreement between parties even though other things may work

<bob> dhull: I think that the policy alg. does fine, I think that what it does is compare two sets of assertions and thats all

<bob> ram: I think that there is a lot of agreement, and therefore that we can get to closure

<anish> even folks in wsp wg want clarity. clarity is lacking in the ws-p specs

<Ram> 3.1.6 Finding Compatible Policies

<Ram> When a client is looking for an endpoint with compatible policy, one common method used is to take the policy intersection between the policy which the client is looking for, and the policy asserted in the WSDL document; a non-empty intersection is sought. The policy used by the client must be written carefully to avoid unexpected results. This is most obvious when the client is not looking for explicit support of a particular kind of response; failing to take

<bob> dhull: It is hard to figure what we should to different

RESOLUTION: LC136 Closed with no action

<scribe> Chair: Section 4.5 of WSP deals with intersection. Full semantics of assertions domain-defined. Can define totally domain-specific alg. or use default. Which one used is differentiated by QName.

<scribe> Chair: Believe we have used default for purpose of comparing policies.

<anish> is domain-specific algorithm pulled in only if there are parameters defined?

TRutt: We have not provided any parameters. IMO don't need domain-specific rules now.

<scribe> Chair: (Anish) forced to use domain-specific if you have parameters.

TRutt: Even with params can use default
... Can if you want. We haven't defined params, so don't need domain-specific rules

Anish: So domain specific is pulled in only if params defined?

Monica: There are other cases w/o parameters. E.g. domain has top-level assertion with empty nested policy expression and you want those to be compatible. By default not compatible.
... (example needs second policy with non-empty)

<scribe> Chair: Testing

Ram: We have reported back on interop scenarios. Have submitted document for review. Hope we have covered all cases we wanted to test. Hope to do testing on this and report progress.

<scribe> Chair: Have folks had a chance to look? Please review if you can.

<David_Illsley> phone died... will look for another battery but don't hold out much hope

Ram: Hope interop testing will show whether real implementations can use what we've done.

<scribe> Chair: Do you believe we have a sound basis for moving ahead with testing?

Ram: Yes, absolutely. Our product teams worked on it quite a bit. We believe this is exactly it and we have covered all the useful cases.

Katy: We totally agree with Ram. We have a good list of cases with good coverage and expect to show good interop.

<scribe> Chair: From chairs of WSP, participants should send contact info to Abbie Barber (sp?) point-to-point so he can provide a pass to get into event.

Ram: Thanks for pointing this out. We will do so.

Katy: Will do.

<scribe> Chair: Given that there are no open issues and that the changes we have made have fulfilled WSP issues, no reason not to move to LC.

<anish> is the document that will be taken to LC: http://www.w3.org/TR/2007/WD-ws-addr-metadata-20070202/

<anish> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8

<scribe> Chair: There being no objections, we shall proceed to LC with the version currently pointed to as the editors' draft on our web site.

RESOLUTION: version http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html?content-type=text/html;%20charset=utf-8 will be LC draft. LC period statutory minimum of 3 weeks.

<scribe> Chair: Please take close look at interop scenarios for identification of potential features at risk

<scribe> Chair: AOB?

Ram: Editors will update NS?

<scribe> Chair: Yes, along with status section.

Ram: Need NS for interop

<scribe> Chair: You know what it will be?

Ram: Yes

<scribe> Chair: With luck, it will be in the document by tomorrow, subject to Philippe's bandwidth constraints.

<scribe> Chair: AOB?

<scribe> Chair: Adjourned