[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] Optional Presence vs. required support
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]