[ebxml-iic] Re: MS conf clause follow up

[jacques <jacques@savvion.com>]

Hi David:

Thanks for your quick reply. I am sharing it with IIC, as it seems
we need to work fast on the Conf Clause for MSG spec and I'd like to see
more feedback before we submit one...
See below my comments.

>Another issue which came up was conformance profiles.  I informed MSG that the
>IIC group would be creating conformance profiles.  They asked if those profiles
>would be in the MSG spec.  My answer was "no -- separate spec".  Was I correct?

Actually, the conformance clause is supposed to be in the spec, as a separate
section.
Let me quote the OASIS Guidelines:
"...The conformance clause is a section of a specification that defines the
requirements, criteria, or conditions that must be satisfied to claim conformance.
The conformance clause identifies what must conform and how conformance can be met.
Typically it is a high-level description of what is required of implementers and
application developers.  It may refer to other parts of the standard.  It may
specify sets of functions, which may take the form of profiles, levels, or other
structures.  Additionally, it may specify minimal requirements for certain functions
and minimal requirements for implementation-dependent values.  It may also specify
the permissibility of extensions, options, and alternative approaches and how they
are to be handled. .."

In other words, it's a kind of meta-level statement telling what part of the spec
need be
implemented, to match a conformance level.


>It is important to the MSG group to define a Baseline (Core) functionality with
>a minimum of elements/parameters/modules.  Conformance profiles beyond this are
>not being discussed.  If there is a specific conformance clause you would like
>to insert in the MSG spec, please let me know.

At this point, I think we all agree to define  the baseline first. But as there may
be later other
profiles/levels, we are very concerned that any explicit "core" vs. "optional"
qualifier in the spec body
(at module level) will bring confusion at that time.
So, even for the baseline, we would like to see a separate, explicit conformance
clause that
defines it, and that explicitly gathers in the same area of the spec all the
requirements to be met.
A kind of check-list for implementors, to go through to make sure they meet the
requirements.
Something like:
--------------------------  conformance clause level 1 (sart) -------

"Level 1 of conformance with this specification is the baseline for any MSH
implementation.
In order to meet this level of conformance, an MSH instance must satisfy the
following conditions:

Condition #1: Implement the specification material in Section 2 about the message
SOAP packaging functions.
Condition #2: Implement the specification material in Section 3 about the core
extension elements.
Condition #3: Implement the specification material in Section 4.1 about the
security  module.
Condition #4: Implement the specification material in Section 4.2 about the error
handling  module.
Condition #5: Implement or use a SOAP messaging over at least one of the two
transport protocols:
(1) HTTP, or (2) SMTP.

Any MSH instance that does not satisfy any of the five above conditions cannot be
said conformant to
the ebXML MS specification neither at Level 1 nor at any level above.

Note: Implementing specification material assumes compliance with the ISO / IETF
keywords
that govern mandatory, optional and recommendation requirements included in the
specification body."

 ------------------------ conformance clause level 1 (end)---------

Note: the sample clause above is just a sample... in fact, we have strong reserve
about security in the baseline,
and would rather see some test-supporting feature instead (like Ping).
We'll suggest this in a more formal proposal this week. (Your input is welcome here
too)

I'd like to add that all this is not just an exercise of style... we'd rather all
focus on  implementations issues and
practical validation in the IIC, but  there are potentially some future legal issues
behind all this, and it is worth
spending time on careful wording now.

>Please keep in mind that the
>MSG, CPPA and BPSS specs are each orthogonal and (at least MSG) must function
>without the other two.

I understand. I guess Imagiri meant more "compatibility" than "interoperability"
(Imagiri?)
But even so it is expected that, say, "some" level of CPPA  be required when
implementing an MSH.
MS V1.05 actually makes several references to CPA specs, (besides using the -
required - CPAid element):
(quote V1.05, section 1.2.2):
"...The important point is that an ebMS-compliant MSH shall respect the in-force
agreements between
itself and any other ebMS-compliant MSH with which it communicates.
In broad terms, these agreements are expressed as Collaborative Profile Agreements
(CPA)...."

So our point is here that if a spec is referring to another spec, the "levels" of
conformance for each one
should be consistent. And again, we may not have an immediate problem with this
today, but
in the future, specs can only become more depending on each other (just a guess)...

Regards,

Jacques

David Fischer wrote:

> Hello,
>
> We discussed some of the concerns from your note in the MSG call today.  I
> specifically raised your concern about deliverySemantics vs.
> duplicateElimination.  The consensus was that MSG is trying to de-couple the
> various elements of Reliable Messaging and that duplicateElimination is really
> the desired function.  There was/is very little concern about backward
> compatibility at this point since other changes (AckRequested) have changed
> anyway.  My personal feeling is that basic message transfer is still compatible
> (v1.0 & v1.1) as long as RM is not specified.
>
> MSG is racing ahead, trying to meet the Jan 1 release to the OASIS membership.
> This means the v1.1 spec must be delivered to Karl Best by Dec 1.  I think
> they/we will make this timeline.  This is also the reason for the weekly con
> calls.
>
> Another issue which came up was conformance profiles.  I informed MSG that the
> IIC group would be creating conformance profiles.  They asked if those profiles
> would be in the MSG spec.  My answer was "no -- separate spec".  Was I correct?
>
> It is important to the MSG group to define a Baseline (Core) functionality with
> a minimum of elements/parameters/modules.  Conformance profiles beyond this are
> not being discussed.  If there is a specific conformance clause you would like
> to insert in the MSG spec, please let me know.  Please keep in mind that the
> MSG, CPPA and BPSS specs are each orthogonal and (at least MSG) must function
> without the other two.
>
> Anything else I can answer?
>
> Regards,
>
> David.
>
> -----Original Message-----
> From: jacques [mailto:jacques@savvion.com]
> Sent: Monday, October 22, 2001 12:06 PM
> To: David Fischer
> Cc: iwasa@fs.fujitsu.com; himagiri@sybase.com; jacques@savvion.com
> Subject: MS conf clause follow up
>
> Hi David:
>
> I guess you are a precious resource to us (in conf clause), as both the MSG TC
> liaison and
> the editor of V1.05!
> Make sure to send me your feedback on the way we could introduce
> a conf clause in the MS specs. Basically, my point is that  adding a conf clause
> would
> take care of what is core and what is optional (at module level), depending on
> the
>
> conformance level...
>
> I think also that it is especially important that the MSG spec  sets the right
> format for the
> conformance clause,  so that other TCs can follow. A separate, explicit clause
> in
> each
> spec will be essential to achieve the "interoperability" between Messaging, CPPA
> and BPSS
> that Himagiri seems to worry about .
>
> On another note, what is the release schedule of MSG specs? (V1.1?)
>
> Regards,
>
> jacques Durand
> Savvion
>
> David Fischer wrote:
>
> > Hi Tony,
> >
> > <<comments in-line>>
> >
> > Regards,
> >
> > David.
> >
> > -----Original Message-----
> > From: Tony Weida [mailto:rweida@hotmail.com]
> > Sent: Sunday, October 21, 2001 8:05 PM
> > To: David Fischer; CPPA
> > Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> > David,
> >
> > I've embedded a couple comments below, prefixed with my initials.
> >
> > Cheers,
> > Tony
> >
> > ----- Original Message -----
> > From: David Fischer
> > To: CPPA
> > Sent: Sunday, October 21, 2001 6:32 PM
> > Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> > Sorry I missed the meeting, it didn't make it onto my calendar.
> >
> > Comments:
> >
> > If end-to-end, signed Acknowledgment is requested, it provides NRR -- in the
> > same way DeliveryReceipt does.  NRR cannot be provided at the
> > BPSS/Application level since MSH does not pass the entire message and thus
> > the Application cannot generate the required Digest(s).
> >
> > TW: That seems like a strong statement.  Signing the entire message is
> > sufficient, but is it always necessary?  I understand that messaging
> > elements may convey information relevant for non-repudiation, e.g., a
> > timestamp.  Such information may also appear in a particular type of
> > business payload.
> >
> > <<In order for NRR to work, it must EXACTLY match the original signature
> > digests -- which includes the MSH headers.  Since the Application doesn't have
> > those headers, it cannot generate those digests.  This does not mean that the
> > Application might not do something similar with only the payload.  Messaging
> > does not stipulate what can be in the payload.  If the Application wants to do
> > something like sign/encrypt the payload prior to passing to the MSH, it can.
> > However, this is not NRR.  This is more like some subset of the original
> > digests/ds:Signature, so the original signature will not match.  In any case,
> > the Application can do whatever it likes and the MSH will provide NRR, if a
> > signed Acknowledgment is requested.>>
> >
> > Since the MSH does not do any application parsing, any Business Level
> > receipts cannot be done at the MSH level.  While the Application cannot do
> > NRR, it can/must provide anything along the lines of "Message verified/being
> > processed" (i.e. Delivery Receipt).  The Application would pass this signal
> > to the MSH with a flag which says "sign this".  While it would not be
> > illegal for the Application to send a signed/encrypted payload to the MSH
> > (would this be S/MIME?), it is not within our model to do so.
> >
> > TW: I expect that some security-sensitive applications will call for
> > transmitting encrypted content between authorized persons or applications,
> > not just between their respective MSHs.  The latter is more likely to
> > compromise security, for example by exposing confidential information to
> > unauthorized persons within an enterprise.
> >
> > <<Not a problem!  The Application may pass anything it wishes to the MSH.>>
> >
> > An Acknowledgment can be requested separately from Reliable Messaging
> > although the only difference is duplicateElimination.
> >
> > I think/agree that MSH signals should be returned synchronously for HTTP.
> > This should be the default.  Maybe we don't need a flag, just make this a
> > requirement (Why would this ever be done asynchronously for HTTP?)  I think
> > I agree with Dale.  This should match the transport method (sync for HTTP,
> > async for SMTP) and should not change per message.
> >
> > Regards,
> >
> > David Fischer
> > Drummond Group.
> >
> > -----Original Message-----
> > From: Tony Weida [mailto:rweida@hotmail.com]
> > Sent: Saturday, October 20, 2001 5:05 PM
> > To: CPPA
> > Subject: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
> >
> > Draft minutes of the October 18 teleconference are attached.  Please send me
> > any additions or corrections.
> >
> > Cheers,
> > Tony Weida
> > Independent CPPA Fan :-)
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>