[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-msg-as4] follow-up on Receipts
Hello,
The ds:Reference is not required in the ebbp:NonRepudationInformation
schema, it is also possible to only include a message part
identifier.
<xsd:element
name="MessagePartNRInformation">
<xsd:complexType> <xsd:choice > <xsd:element name="MessagePartIdentifier" type="bpssignal:non-empty-string"/> <xsd:element ref="ds:Reference"/> </xsd:choice> </xsd:complexType> </xsd:element> This profile could constrain the value of the MessagePartIdentifier to
MIME part IDs and XML IDs.
More generally, when
generating the Receipt, can the ebMS handler determine itself which elements in
the message it generates ds:Reference elements for, or should it reuse the
ds:references from the incoming ebMS message and recompute hashes for
them? If the latter, the WSS module and the Receipt
generation can't be decoupled as much as is described below.
On the other hand, there are multiple reasons why the receipt could
involve digest for diffent and/or different structures:
1) If the Receipt is generated by the ebMS module, would the Receipt
contain a digest of the decompressed payload? The WSS module
operates on the compressed payload.
2) If AS4
is to be compatible with a future Bundling profile, I guess the receipt
should sign the eb:UserMessage and generate separate receipts for each
user message. AS4 now requires the WSS module to sign the full
eb:Messaging structure, which (when using bundling) could include multiple user
messages.
Pim
From: Timothy Bennett [mailto:timothy@drummondgroup.com] Sent: 03 February 2009 17:30 To: Durand, Jacques R. Cc: ebxml-msg-as4@lists.oasis-open.org Subject: Re: [ebxml-msg-as4] follow-up on Receipts Durand, Jacques R. wrote: 0D4373E9E1236F42AB63FD6B5B306AA3BCD43C@SV-EXCHANGE.fjcs.net type="cite">One of the important aspects of the discussion on performance with regard to digest computation relates to the architecture of the ebMSv3 specification that supports the different processing modules as being swappable black boxes. That is, the inbound stream passing through the security module, then the reliability module, then the ebMS module, etc. In this context, the code that eventually generates the NRR receipt is not guaranteed to have access to the digest computed by the Security Module and if strict separation of modules was enforced, then the code that generates the NRR receipt would have to compute the digest of the original inbound message again. That's the context of the performance question for large payloads. Naturally, implementers can create integration points between modules for sharing information, but none of those interfaces are standard, and for implementers that are serious about black boxing the processing modules, this can be problematic. There was no such "architectural" ideals with AS2 as there seems to be with ebMSv3, and it was in this context that some other ideas was *brainstormed* on the call yesterday -- including making the digest field in the NRR receipt optional (see #2 below). The computed digest is a necessary legal data field for many types of transactions (retail/banking), but a simple "ebMSv2-like" Ack may be sufficient for other types of transactions. 0D4373E9E1236F42AB63FD6B5B306AA3BCD43C@SV-EXCHANGE.fjcs.net type="cite">--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]