conformance

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: conformance

>I used the simple criteria that if remebering any state is required it
>goes in full option.

Makes sense. Agree we need a "stateless" RM profile.

>> But the RM capability on the sender side should also enter
>> in the definition of conformance profiles I think.
>
>I am not sure what difference it would make for interop.  The sender
>selects the options
>it wants when it populates the request parameters.  If it does not
>support a feature, it will
>not ask for it in the request.

Maybe we are talking of two different things here, for two different purposes:

(1) if the goal is for a Sender to figure whether a Receiver can honor
its RM requests, that sounds like an RMP functionality.
For example, what error messages need be sent after receiving a request one cannot
support (new fault codes). I believe we'll need that (part of .
If the idea is to know before any message exchange,
that is probably out of scope for now (e.g. some form of query, or agreement management.

(2) if the goal is to state what the minimum requirements are for an RMP
implementation to be declared conforming, then I would expect support for a
fair number of features both for sending and receiving, which would guarantee upfront
some RM interop among all partners.
But now I am not sure we should even set the bar anywhere: given that some devices
may be extremely light (e.g. "stateless", just able to send back Acks, nothing more) that would
not be very meaningful. Another approach would be to declare conforming any
coherent combination of RM features, provided that the feature implementation conforms
to the spec.
And there may be some required associations (e.g. which errors should be supported
with which features.) Then we can fallback on some form of (1) above to figure out
the interop aspects. Thoughts?

Jacques

>
> Jacques
>
>
> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com]
> Sent: Wednesday, January 07, 2004 1:51 PM
> To: wsrm
> Subject: [wsrm] Discussion of Conformance Points for WS-Reliability
>
>
> I propose just two levels of conformance for WS-Reliability message
> receivers:
>
> Simple: The receiver can handle guaranteed delivery requests
> Full:     The receiver can handle any WS-Relibility request
>
> A receiving implementation may claim conformance as a Simple receiver,
> or as a Full receiver.
>
> A sender would only have to implement the portions of the protocol that
> they use, as indicated
> by the QOS request parameters they select.  Thus we do not need
> conformance classes for  senders.
>
> What do you think?