Re: [ebxml-msg] FW: [ebxml-iic] Conformance Clause update & issues

[Christopher Ferris <chris.ferris@sun.com>]

By all accounts, the major issues surrounding RM was that
many felt that because it didn't adequately address "end-to-end" reliability
that it was broken.

How we choose/chose to "fix" it, should not be predecated on backward
compatibility with 1.0, IMO. We say nothing about a 1.1 implementation
being able to interoperate with a 1.0 implementation. Much of
what is in 1.1 is largely unchanged from 1.0, so that is a "good thing"[tm].

Since the "function" of deliverySemantics was to indicate whether
a message was being delivered with OnceAndOnlyOnce or BestEffort
which then combined with information in the CPA as to the
method (ebXML) by which that deliverySemantics was to be effected (by
requiring an ack) has been replaced with a specific AckRequested element,
I think that it is safe to say that whether we choose to reuse the
old element name, with a set of new values, or replace the element
name (with the same set of new values) is immaterial.

Seems to me that what the IIC TC should be focused on is 1.1,
working closely with us to develop the conformance criteria to ensure
interoperability, etc. and not focusing on 1.0 at all. My $0.02.

Cheers,

Chris

David Fischer wrote:

> This shows another concern about the change from deliverySemantics to
> duplicateElimination.  Since (as I remember) this is mostly a cosmetic change,
> perhaps we should change back?  Functionality would remain the same.  We need to
> discuss this.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: jacques [mailto:jacques@savvion.com]
> Sent: Saturday, October 20, 2001 2:35 PM
> To: ebxml-iic@lists.oasis-open.org
> Cc: jacques@savvion.com
> Subject: [ebxml-iic] Conformance Clause update & issues
> 
> 
> Hi all:
> 
> This is  an update on the Conformance Clause status.
> Your input  / opinion is actually requested...
> 
> As you may know, the  Messaging Services spec is currently  revised,
> which makes it a moving target for conformance clause work - but also
> an opportunity. A preliminary draft (V1.05) is circulating.
> 
> On the positive side, V1.05 is addressing conformance concerns much more
> 
> explicitly than V1.0. A set of core features is being proposed. To
> summarize:
> - SOAP envelope and extensions
> - Security and Error handling modules
> 
> This does not exactly match what the CC working group is currently
> planning
> as "base conformance level", but is close.
> (We are mostly targeting a baseline conformance level that supports
> basic interoperability,
> and that could easily be remotely tested. So features such as "security"
> may not be required
> here.)
> 
> Another good thing in V1.05 is the grouping of features in modules,
> which are logical
> (and implementation) entities that will make it easier to define
> conformance levels or
> profiles.
> 
> A not so good thing is that compatibility with 1.0 seems broken.
> New QoS elements such as "duplicateElimination" are being added.  That
> is rather brutal
> for a minor revision that early after the initial release. (
> compatibility breaks would not
> be a problem for major releases, and it would be better to "space" them
> as much as possible).
> 
> But another aspect of V1.05 that IIC-CC is more concerned with, is the
> inclusion of
> a conformance clause.
> Here please review the attached comment / feedback that I propose
> to communicate to the MS TC. Your comments are welcome.
> 
> Regards,
> 
> Jacques Durand
> chair of the Conformance Clause working group
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> The latest evolution of the MS specification  (1.05) is explicitly partitioning 
> the MS features into core (mandatory)features  vs. optional features. 
> We see the following problems with this:
> 
> 1. This preemptively specifies the conformance clause as built-in in the body 
> of the specification. It will then be difficult/confusing to specify several 
> levels or profiles of conformance, as each feature module in the spec is 
> qualified up-front as either "core" or "optional". The reality is, the same module 
> may be optional for a level of conformance and mandatory for another. 
> 
> 2. This up-front qualification of modules of features will then likely collide with
> the Conformance Clause. The OASIS Conformance Requirement Guidelines recommends
> this clause to be a separate section, added to the specification.
> The conformance clause addresses practical criteria and concerns that the core
> specification may want to remain somehow independent from, and that may 
> actually evolve independently from the main body of the specification: 
> usage profiles, ease of test, interoperability agenda, etc.  
> 
> 3. The way the spec is currently written, implicitly defines a 
> "core" conformance level, by making everything else optional. Because the remaining 
> optional features are not tied to any conformance level, it is then sufficient 
> for a vendor to implement just the core features, and yet claim to be 
> technically "fully compliant" with the entire spec,
> (without having to refer to any conformance level) 
> Such a claim will be technically right, as everything else is optional...
> 
> 4. At a more detailed level in V105, we see the following problems with an 
> arbitrary partitioning core/optional:
> - Some Core modules (non-optional), like Security module, is actually de-facto 
> optional as it may be void of its elements (0 or more ds:signature) and may 
> actually be completely absent from the header. 
> - the "optional" quality of a module can actually be conditional: 
> the Message Status Service is listed under Optional features, but it is actually 
> NOT optional when the Reliable Messaging module is used.
> 
> -----
> 
> As a consequence, we suggest that the MS specification does not directly 
> qualify its modules of features as core vs. optional. 
> (however, formal/logical dependency rules between modules, e.g. M2 is required 
> if M1 is implemented, still belongs to the main spec)
> Only an exhaustive implementation will be "fully conformant". 
> 
> A conformance clause should be added that defines levels/profiles of conformance, 
> and for each of these, which modules are required and which ones are optional. 
> (in other words, we believe there are two usage of OPTIONAL keyword: one normative, 
> the other one about conformance, and that they should not be confused.)
> More detailed conformance requirements can be specified in addition in the clause.
> The IIC working group offers to cooperate with MS TC in this effort.
> 
> 
> 
> 
> CC_and_MS105.txt
> 
> Content-Type:
> 
> text/plain
> Content-Encoding:
> 
> 7BIT
> 
>