RE: [wsrm] Optional Presence vs. required support

Jacques,

I agree that we MUST always say things of the form "a Sender MAY
insert..." and not "a message May have..."  The
permission is granted to the sender, not to the
message.     Your formulation of the solution for
this particular case would work but the resulting text will be more
complex than using another word for MAY.  For example, it could say
"a sender is allowed to insert this or that in a
message."  By avoiding the word MAY, you also avoid the need to
qualify "MAY" by saying "a Receiver MUST be able..."
since that is implicit throughout the specification except where MAY or
OPTIONAL is used in the RFC2119 sense.

Regards,

Marty

At 09:33 PM 9/29/2003 -0700, Jacques Durand wrote:

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:]

Sent: Sunday, September 28, 2003 5:02 PM

To: Jacques Durand

Cc: ; 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:] 

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: ;  

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

 

*************************************

Martin Sachs

standards architect

Cyclone Commerce