RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001

[David Fischer <david@drummondgroup.com>]

OK with me.

I imagine there will be lots of business signals and it is the job of the MSH to
support whatever BPSS wants to define.  The only problem is when BPSS tries to
define functions which overlap Transport, Routing and Packaging functions.  At
this point, I don't think this is the case.

David.

-----Original Message-----
From: Tony Weida [mailto:rweida@hotmail.com]
Sent: Monday, October 22, 2001 11:31 AM
To: David Fischer; Christopher Ferris
Cc: CPPA
Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


Hey, I don't mind answering a rhetorical question :-)
Please see below.

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "Christopher Ferris" <chris.ferris@sun.com>
Cc: "CPPA" <ebxml-cppa@lists.oasis-open.org>
Sent: Monday, October 22, 2001 11:59 AM
Subject: RE: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001


> OK Chris, ebXML-MS v1.0 section 6 (see also ebXML Requirements sec 7.6).
The
> functions defined for MS are:  Header Processing, Header Parsing,
Security, RM,
> Packaging, Error. . .
>
> The name of the group is Transport Routing and Packaging.  Since
Signatures have
> to be applied after Packaging then Signatures MUST be a function of the
MSH.
> Since we are performing Packaging, we also must be performing UnPackaging.
> There is nothing preventing the Application from seeing the all the
headers but
> that is not our model.  If the MSH is doing the Header Processing/Parsing,
why
> would the headers be passed to the Application (rhetorical question).
>
> It is the function of the MSH to perform NRR.  If the Application wants to
> duplicate that functionality, I guess it conceivably could, but why
(another
> rhetorical question).

TW:  Because, I believe, business people will care about business documents
exchanged by business applications.  Messages exchanged by MSH
implementations are technical details.  I imagine that lawyers (Jamie?)
might agree to accountability as soon as message receipt is confirmed by the
receiving party's MSH, but that alone doesn't meet the business need.

> Regards,
>
> David.
>
> -----Original Message-----
> From: Christopher Ferris [mailto:chris.ferris@sun.com]
> Sent: Monday, October 22, 2001 8:20 AM
> To: David Fischer
> Cc: CPPA
> Subject: Re: [ebxml-cppa] CPPA teleconference minutes: October 18, 2001
>
>
> David,
>
> Please see my comments below.
>
> Cheers,
>
> Chris
>
> David Fischer wrote:
>
> > 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).
>
>
> Says who? Nothing in the specification prevents the entire unadulterated
> message from being passed to the "application". The "application" can
> most certainly do NRR. Please keep in mind that many believe that ONLY
> the "application" can do NRR.
>
>
> >
> >
> >
> > 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.
>
>
> There's nothing in the spec that says that MSH functionality (and I
> don't necessarily consider signing to be a function of an MSH mind you)
> cannot be made available to higher levels of software.
>
>
> >
> >
> >
> > An Acknowledgment can be requested separately from Reliable Messaging
> > although the only difference is duplicateElimination.
> >
> >
> >
> > I thing/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.
>
>
> I agree that the MSH "signals" should be returned synchronously
> on the HTTP response in the HTTP binding.
>
>
> >
> >
> >
> > 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>
>