Doug,
I think issues 6 and 9 make issue 24 more relevant/important and I can
see at least a solution that covers all three. It certainly makes sense
to think about them together and perhaps even find a single/common solution.
One question though I have about the existing RM policy assertions is:
are they (inactivity timeout, base retransmission interval, ack
interval) meant to be shared between RMS and RMD or are they meant as
configuration information for implementations? By shared, I mean shared
by both the RMS and RMD (and not just attached in a WSDL document).
Thanks.
-Anish
--
Doug Davis wrote:
>
> What's the relationship between this issue and issues 6, 9? They seem
> very similar - almost like 6 and 9 are a subset of 24. Would it make
> sense to try to find a single/common solution that covers all?
> thanks,
> -Doug
>
>
> Ashok Malhotra <> wrote on 09/14/2005 03:43:40 PM:
>
> > This is in response to Sanjay's note asking for a proposal for issue
> i024.
> > In this case, though, what we are asking for may be a clarification
> and not a change.
> >
> > The WS-RM Policy spec defines a RM assertion. It also specifies how
> this assertion
> > may be attached to WSDL. What is does not specify is the motivation
> behind the
> > assertion, how it is used and the messages it applies to. We would
> like this clarified.
> >
> > It is clear that the RM assertion is an 'informational assertion' in
> that it is a
> > property of the sequence and not a property of the messages in the
> sequence. As such,
> > it does not make sense for each message to include this information.
> >
> > Second, policy information is meant to be conveyed by one party in a
> conversation to
> > the other. In this case, the assertion seems to specify
> implementation parameters
> > that may be private to the RMS or the RMD. If so, it does not need
> to be part of the
> > specification.
> >
> > If, indeed, the RM assertion is to be conveyed from the RMS to the
> RMD it can be
> > done as a header in the CreateSequence message. The RMD can respond
> with a header
> > in the CreateSequenceResponse by agreeing, disagreeing or making a
> counter proposal.
> >
> > If the RM assertion has to be conveyed from the RMD to the RMS, this
> has to be done
> > before the CreateSequence message and requires a new protocol element.
> >
> > All the best, Ashok
> >