See also: IRC log
<trackbot> Date: 18 August 2009
<Bob> zakim aacc is Sreed
<fmaciel> do you see that?
<Bob> scribe: Paul Nolan
<Bob> scribenick: PaulN
Agenda is accepted
RESOLUTION: All three sets of minutes from the August F2F are accepted
Bob: need chair for 8th Sept - Yves?
<dug> you skipped a few topics
Bob: Yves will let group know if he can not make it.
Yves: Partial put will be done by end August
Bob: 6724 Doug will complete 28th August
Bob has reviewed the expected completion dates of outstanding issues
Paul will post details for travel
<dug> I've fixed ALL of the typos that Ram noticed.
Ram: more time requested for our review of MEX and RT
<dug> do people prefer WS-Fragment or WS-Fragments ?
<Bob> +1 Yves
Bob: "WS-Fragment" will be used since there is no objection
Doug: can people please review
Bob: should we accept the spec and
raise issues for open questions?
... next week we will review this proposed draft and see if we can use it as a starting point
Bob: no objections to opening new issue 7235
<dug> Unless otherwise noted, all URIs are absolute URIs and URI comparison MUST be
<dug> performed according to [RFC 3986] section 6.2.1.
Doug: new issue 7270. Specs consistency issue
Bob: new issue accepted
Bob: we need to resolve an important question before going too far
Ashok: reviewed two points he has raised
Wu: should only EP related policies will be attached inside the EPR
Ashok: only EPR related policies should be attached in the proposed way
Wu: to clarify. we will define a
... one namespace fo all specs?
<dug> +1 one NS per spec
<Wu> +1 Bob
Bob: should we do one namespace per
... do we more or less agree on the proposed direction?
<Wu> Bob's point as I understand (agree) is to have one policy namespace per spec for ease maintenance.
<Ashok> I think that would be fine
Bob: are we agreed on direction?
RESOLUTION: Generlly agreed with Ashok's points in the bugzilla and one policy namespace per spec
<dug> In cases where it is either desirable or necessary for the receiver of a request that has been extended to indicate that it has recognized and accepted the semantics associated with that extension, implementers are encouraged to add a corresponding extension to the response message.
<dug> (that's Gil's text)
<dug> Ram's text: In cases where it is either desirable or necessary for the receiver of a request that has been extended to indicate that it has recognized and accepted the semantics associated with that extension, it is recommended that the receiver add a corresponding extension to the response message. The definition of an extension should clearly specify how the extension that appears in the...
<dug> ...response correlates with that in the corresponding request.
Gpilz: reviewed proposal
Doug: is this issue specific to just the one spec?
Gpilz: All specs affected
no objections to proposal
RESOLUTION: Ram's amendments to Gil's proposal accepted for the resolution of Issue-7206
RESOLUTION: Extend the resolution of 7206 to all WS-RA specs
<dug> +1 to cwna
<gpilz> +1 to cwna
Gpilz: complexity is dealt with by explicity stating cobinations of extensions that are supported.
Wu: how do we advertise these extensions?
Gpilz: each new extension defines itself
Wu: should we use Policy?
... should we use WSDL to advertise?
Bob: notes that WS-Policy should be used to determine compatible extensions
RESOLUTION: Resolve Issue-7204 by closing with no action
<Ram> -Issue-7160 Eventing:check 2119 terms http://www.w3.org/Bugs/Public/show_bug.cgi?id=7160 -Davis
<Bob> Ram requests one more week to review
RESOLUTION: Resolve Issue-7191 as proposed
RESOLUTION: Resolve Issue-7193 as proposed
RESOLUTION: Resolve Issue-7195 as proposed
RESOLUTION: Resolve Issue-7196 as proposed
RESOLUTION: Resolve Issue-7197 as proposed