OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC