RE: [wsrm] Optional Presence vs. required support

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

That's another "option"...

I agree many times we abuse these keywords

(instead of saying "a message MAY have this or that"

we probably should say "a Sender MAY insert this or that in a message"

and state explicitly after, that "a Receiver MUST be able to process all features of a message"

i.e. use these keywords only directly related to an implementation.

let me think more about it.

I know we had similar problem in ebMS...

 

Jacques

-----Original Message-----
From: Martin Sachs [mailto:msachs@cyclonecommerce.com]
Sent: Sunday, September 28, 2003 5:02 PM
To: Jacques Durand
Cc: tom@coastin.com; wsrm
Subject: RE: [wsrm] Optional Presence vs. required support
Importance: Low

It would be better to completely avoid using the terms "optional" and "may" when the context is not that intended by RFC2119.  Avoiding the terms will provide a much stronger assurance against misinterpretation than including a statement that might be overlooked, in the conformance section.  English has other words and phraseology that can be used where the semantics are "may" or "optional" but support is nonetheless required, e.g., the 4th paragraph  of (1) below. In the CPPA specification, we completely avoided using the terms "optional" and "may" when the sense is not as intended by RFC2119.

I also want to remind everyone that RFC2119 does not REQUIRE the use of upper case when its keywords are used in the RFC2119 sense.  That is a common practice that but it's not normative.  Therefore, use of upper case when the context is that intended by RFC2119 still requires an explanation in the conformance section and that explanation might be overlooked.

Regards,
Marty

At 05:01 PM 9/26/2003 -0700, Jacques Durand wrote:

Tom:

The following might help to clarify the notion of conformance in the spec:

1. how developers should interpret RFC2119 keywords
(RFC2119 is coming short of avoiding ambiguous interpretation):

(Extracted from the ebMS conformance section: )

"[an implementation is conforming if] It complies with the following interpretation
of the keywords OPTIONAL and MAY:  When these keywords apply to the behavior of the implementation, the implementation is free to support these behaviors or not, as meant in [RFC2119]. 

When these keywords apply to message contents relevant to a module of features, a conforming implementation of such a module MUST be capable of processing these optional message contents according to the described semantics."

I find these general terms clear enough, and avoiding the drawback of reasoning in terms
of "Service" vs. "client" , which may become tricky (as the service side may also
initiate messages)

2. Adding a Conformance clause section in the spec,
gives the flexibility to describe [possibly several] levels or profiles of conformance,
and their interoperability relationship.

In other words, when we use MUST, SHOULD, etc., these should be understood
as being within the scope of a feature , i.e. "if feature XYZ is used..."
Then in the conformance clause we can make higher-level statements about which features
MUST be supported in order to conform [to a profile].

Regards,

Jacques

-----Original Message-----
From: Tom Rutt [mailto:tom@coastin.com]
Sent: Friday, September 26, 2003 2:25 PM
To: wsrm
Subject: [wsrm] Optional Presence vs. required support

We need to get some important discussion on the conformance aspects of
our protocol.

We have several syntactic mechanics which have the presence of a
subelement in a header
(or an attrbibute of some header subelement) signalling to the receiver
that a particular
protocol mechanism is in use.

Interoperability would be greatly increased if all our protocol
mechanisms are requred
to be supported by all RMP (at least on the service instance end).

The Client of the service would be the one always choosing whether the
protocol feature is used.

I realize that this global interop goal is probably not attainable (not
everyone needs ordering),
but we should limit the number features which are not required (i.e,
optionsal) for conformance.

Anyway, we need to use careful wording  in the protocol syntax
descriptions when an element (or attribute) is specified as "able to be
not present".  In each case we need to clarify the support
required for conformance claims.

I suggest we could have conformance based on feature:

eg:
- acknowledgment conformance class
- acnlowledged duplicate conformance class
- acknolwedged duplicatate elimination and ordered delivery conformance
class

Now the next question is if we need to further parameterize our
conformance claims by
the RM-Reply patterns supported by an implementation:
- response reply pattern
- callback reply pattern
- poll reply pattern

And then again we have the support for request/response WSDL operation
type.  Is
this going to be another conformance point parameter.

Thus we have 3 by 3 by 2 conformance matrix.  How many of those 3D
matrix cells do we
want to give separate names to?

Tom Rutt
WSRM Chair



--
----------------------------------------------------
Tom Rutt                email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133





To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com