review of agenda

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

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 ?

<silence>

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>

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.

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

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.