Re: Non-anon extensibility and policy intersection

OK, here's my second attempt at a reply.  The first one went off in the
weeds when I realized I didn't completely grok the way nested policy
assertions work (as opposed to policy expressions that nest), and that
I'd mistakenly taken "intersection" in "intersections between all pairs
of compatible alternatives" to mean "intersection", since alternatives
are, after all, defined as sets.  BZZZT!  "Intersection" here means
"union", as in "If two alternatives are compatible, their intersection
/[sic]/ is an alternative containing all of the assertions in both
alternatives."

(Please imagine a lengthy rant on the proper use of mathematical terms
and notations here).

So ... what it seems to come down to is whether the relevant pairs of
assertions are compatible.  For example, if we're intersecting

<ExactlyOne>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing> <!-- I
support non anon responses -->
    </All>
<ExactlyOne/>

with

<ExactlyOne>
     </All>
        <addressing><Policy><nonAnon/></Policy></addressing> <!-- I
support non anon responses -->
        <mailto/> <!-- I allow responses to go to mailTo (and nowhere
else unless I specifically say so) -->
    </All>
</ExactlyOne>

then the intersection will be the second policy if the two assertions
are compatible, or if mailto is ignorable and the intersection mode is
lax.  It will be empty otherwise.

As far as I can tell, the two assertions cannot be compatible, even if
mailto and addressing have the same type, since one has a nested
assertion, but they don't both have a nested assertion.  So the
intersection mode has to be lax and mailto has to be ignorable.

Should we even be doing this at all?  The purpose of policy intersection
is "to limit the policy alternatives to those that are mutually
compatible."  Intuitively, and from the name "intersection" this would
mean the more specific of the two, in this case the second one (I
support non anon responses if the destination is mailto").  In a
slightly different case, if one policy says "mailto or http" and another
says "http or jabber", I would expect the intersection to be, well, the
intersection, namely "http".  So it seems that policy intersection is a
valid too here, if we can make it work.

Unfortunately, if we make things like "http" and "mailto" ignorable,
then it appears they won't intersect properly with each other.  E.g.

<ExactlyOne>
    <addressing><Policy><nonAnon/></Policy></addressing>
    <http ignorable = "true"/>
    <jabber ignorable = "true"/>
</ExactlyOne>

intersected with

<ExactlyOne>
    <addressing><Policy><nonAnon/></Policy></addressing>
    <http ignorable = "true"/>
    <mailto ignorable = "true"/>
</ExactlyOne>

gives (I think)

<ExactlyOne>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
    </All>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
        <http ignorable = "true"/>
    </All>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
        <mailto ignorable = "true"/>
    </All>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
        <jabber ignorable = "true"/>
    </All>
    <All>
        <http ignorable = "true"/>
    </All>
    <All>
        <http ignorable = "true"/>
        <mailto ignorable = "true"/>
    </All>
    <All>
        <http ignorable = "true"/>
        <jabber ignorable = "true"/>
    </All>
    <All>
        <jabber ignorable = "true"/>
        <mailto ignorable = "true"/>
    </All>
</ExactlyOne>

I'm assuming here that statements like "if each assertion in A that is
not an ignorable policy assertion ..." are /true/, as per usual
mathematical usage, if there are no such assertions.  If not, then the
intersection is (again, I think)

<ExactlyOne>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
    </All>
</ExactlyOne>

Neither of these is what we want here, nor is the strict intersection
which is (I think) empty.  What I would hope to see here is

<ExactlyOne>
    <All>
        <addressing><Policy><nonAnon/></Policy></addressing>
        <http ignorable = "true"/>
    </All>
</ExactlyOne>

Or something equivalent (except, of course, I don't need to see the
"ignorable" part -- it's just there in an attempt to make the machinery
work).

Tom Rutt wrote:
> This is similar to the use case expressed by anish:  (see below:
>
> David Hull wrote:
>> A while ago I suggested that we have a way of saying things like
>> "non-anon response endpoints must be mailto: (or fit some other
>> pattern)".  Our decision was to leave this out of scope, which is fine
>> with me, but we want to be sure not to disallow it.
>>
>> Suppose I make an assertion, basically "the service support non-anon",
>> generically.  Later, you want to refine that by saying, "Well, actually,
>> the service only supports mailto: non-anon".  As I understand it, policy
>> intersections are aimed at this sort of thing.
>>
>> However, if I intersect a policy that says "non-anon allowed" with one
>> that says "mailto: only", I get the empty set, since the two assertions
>> are different.  I would like to get "mailto: only".
>>   
> If you tread MailTo:only as a further constraint on the usage of
> NonAnon , you might be able to use the
> same composition method as would be used with wsrm make connection.
>
> I copy an earlier email on compostion with ws rm and its make connection
>
> ---
>>
>>   
> Anish Karmarkar wrote:
> >
> > Below is the usecase that I mentioned on the call:
> >
> > The endpoint can only send messages on the 'back-channel' it will not
> > open a new connection to send messages (firewall does not allow it).
> > The endpoint also supports (but does not require) WSRM. What this
> > means is:
> >
> > 1) When wsrm is not used it requires the anon URI for responses.
> > 2) When wsrm is used, it requires the MC template (non-anon URI per
> > ws-addr) for responses.
> >
> > -Anish
> > --
> >
> Response senders's Policy:
> Policy.for.Anish.Use.case.using.Alterntative.G
> ......(explicit.support.claims,.empty.=.full support, nested assertion
> implies constraint)
>
> <Policy>
> ...<ExactlyOne>
> ......<All>
> .........<wsa:Addressing>...<--.Addressing.required,.Constrained to
> nonymous.responses.-->
> ............<Policy><wsa:AnonymousResponses./></Policy>
> .........</wsa:Addressing>
> ......</All>
> ......<All>  <-- use addressing, nonAnon constrained with addiional
> requirment of Make Connection and use of RM )
> .........<wsa:Addressing>..<--Addressing.required,.Constrained to
> NonAnon.Responses.-->
> ............<Policy><wsa:NonAnonymousResponses./></Policy>
> .........</wsa:Addressing>
> .........<wsrmp:RMAssertion.>..<--.RM.required.-->
> ............<wsp:Policy>.
> ...............<--..any.nested.policy.is.asserted.here.-->
> ............</wsp:Policy>.
> .........</wsrmp:RMAssertion>
> ........<wsmc:MCSupported/>..<--.Make.Connection.URI.required.for.responses-->
>
> ......</All>
> ...</ExactlyOne>
> </Policy>
>
>