TomR: Addr did the wsdl, why not
the policy?
... concern is that there will be a void if left unanswered

Gil: I don't see how we can be
tasked on how to put policy in an epr.

<TRutt_> WS addressin has
decided how to attach wsdl to the EPR, we could do
otherwise

Ram: MEX seems to be developing
as a way to get this done

Tom: this method is not yet on a
standards track

Anish: Why would MEX stop a wg
from defining the functionality it needs

Katy: MEX seems to be the right
place to do this work

Anish: Given that this is a
proprietary spec, I don't know what version is considered
... also how does it deal with attaching a policy to an
epr?
... does mex deal with packaging a policy with an epr?

<TRutt_> From ws-policy
framework 3.2 “ Definition: A policy alternative
vocabulary is the set of all policy assertion types within the
policy alternative.] When an assertion whose type is part of
the policy's vocabulary is not included in a policy
alternative, the policy alternative without the assertion type
indicates that the assertion will not be applied in the context
of the attached policy subject.”

TomR: above point is in
discussion within WS-Policy
... Alternative H is a brute-force method that skirts the
negation issue
... I think that we need to wait until WS-Policy decides

Anisk: Consider negation and the
none uri as separate issues
... do you think that your response works for both types.

TomR: Depending on how the
negation issue will temper which resolution we pick

Anish: Is it what constitues a
vocabulary in general or is it related only to nexted
assertions?

TomR: Most of the problem is from
nested assertions
... there are also issues with regard to the definition of
vocabulary
... this may be a vocabulary scoping rules

Anish: Some policy wonks say that
there is no negation, just something is not defined

Policy subject (viz Anish email)

<TRutt_> There was a question
from ws-policy members on the conformance to ws addressing,
with respect to support for types of resonses

<dhull> +1 (at least)

Anish: we do not define what wsam
means
... what does it mean to assert the wsam: assertion
... Second, then is a statement that such an assertion may not
apply to a port type

<gpilz> +1

Anish: Does it mean soap binding,
does it mean core?
... What if I want to not support the none uri (one way messafe
with faults, for example)

Ram: Alt G is a solution that
defines what we need

<TRutt_> The "none" uri is
just a special way to say that a partcular message is purely
one way, it can be used regardless of what "response" types are
supported/required for messages which expect a response of
fault. I think we can word things to get around this none
problem

Anish: Even in alt G does not
specify if the soap binding is used or not. i.e. what spec are
we making an assertion concerning

TomR: It is important to know
what the client can do. Anish, please clarify what you mean by
none

Anish: what assertion are you
making and what spec does it apply to

Ram: we can consider both
possible outcomes from the WS-Policy froup
... if negation does not exist, would that take away our
concern about none?

<TRutt_> The 'None" uri
implies that no response is expected. We could define the other
policy assertions to only apply for cases where responses are
expected, It is a matter of how we word the assertions

Anish: For me it would

Ram: What is the right thing in
our opinion?

David: I assumed that the
assertion applied to the subject, that means the core spec
would be used and applied to the appropriate binding

Gil: I am -1 on separate abstract
and non-abstract assertions

Anish: Are you proposing a
context dependant assertion?

Gil: That is pretty much it
... I don't agree to the restriction prohibiting an absract
assertion
... I also don't like to define the assertion to apply to only
one spec.
... spelling it out and tying it to spicific documents is a
good thing to do