[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Receipts and reception awareness, and AS4 WD15.
Hello,
I've been looking at the issue of the receipt format for
reception awareness a bit more.
It looks to me as if putting the message identifier in the
MessagePartIdentifier (as I proposed last week) is not
right, as the element seems to be for identification of
message parts, not messages. Instead, my proposal is to use
the values of the referenced message parts, which are
included in the eb:PartInfo of the received message, and
have as many of these are there are parts in the message.
Optionally, the SOAP envelope MIME part (the "start" part
in the SOAP with attachments message) could be referenced
too.
Basically, the receipt now has the same content in both
"reception awareness" and "NRR" uses: a list of message
parts. In the former use, the receipt use the structural
identifiers in the ebMS SOAP-with-attachments message. In
the latter, it uses the XML Dsig structural identifiers
computed by the WSS module. The difference is that in the
NRR case, the receipts do not cover the full SOAP message
but only the bits that are signed. In both cases the
receipts can be automatically generated from the received
message using a small number of lines of code.
The latest update (WD-15) is modified to incorporate this
proposal, so please review thorougly. WD15 also includes
Jacques' proposal for (ii) too, so the document should be
complete by now.
Pim
-----Original Message-----
From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: 02 May 2011 13:28
To: 'Theo Kramer'; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups -
AS4-Profile-csd04-wd-13.odt (AS4-Profile-csd04-wd-13.odt)
uploaded
Hello Theo,
I think you're right on (i). The schema requires some
namespace-qualified content in the eb:Receipt, so it cannot
be empty. In creating examples for the spec I only looked
at the cases where the ebBP element is used, with
WS-Security, and I didn't check this case.
One solution is to change the spec to ALWAYS use the
ebbp:NonRepudiationInformation element, as follows:
The ebbp:MessagePartNRInformation element has a choice
content. In cases where the original message was signed
using WS-Security, the ds:Reference elements in the received
message (validated by the WS-Security module in the
receiving MSH) can be used in generating a Receipt, as
currently already specified in the spec. This uses the
second option in the type definition:
<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>
Now to address your comment, we could change the profile and
use the first choice in situations where no WS-Security was
used in the received message, i.e. cases where there are no
ds:Reference elements that can be reused. In this case,
the first option in the type definition is still an option.
I would propose that the profile REQUIRES the content of the
NonRepudiationInformation element to be a single
MessagePartNRInformation element with MessagePartIdentifier
content, with value set to the eb3:MessageId of the received
message.
A valid Signal Message based on this would look like the
following:
<eb3:SignalMessage>
<eb3:MessageInfo>
<eb3:Timestamp>2011-05-01T12:26:11.176Z</eb3:Timestamp>
<eb3:MessageId>d1e7_messageid</eb3:MessageId>
<eb3:RefToMessageId>orders123@buyer.example.com</eb3:RefToMe
ssageId>
</eb3:MessageInfo>
<eb3:Receipt>
<ebbp:NonRepudiationInformation>
<ebbp:MessagePartNRInformation>
<ebbp:MessagePartIdentifier>orders123@buyer.example.com</ebb
p:MessagePartIdentifier>
</ebbp:MessagePartNRInformation>
</ebbp:NonRepudiationInformation>
</eb3:Receipt>
</eb3:SignalMessage>
These receipts would do fine for the "Minimal Profile".
I'd be interested in other views on this, and I'll let
Jacques and others respond to (ii).
Pim
-----Original Message-----
From: Theo Kramer [mailto:theo@flame.co.za]
Sent: 29 April 2011 13:03
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Groups -
AS4-Profile-csd04-wd-13.odt (AS4-Profile-csd04-wd-13.odt)
uploaded
On 22 Apr 2011, at 10:10 AM, pvde@sonnenglanz.net wrote:
>
> Based on comments from TC Admin (Paul Knight), I reviewed
the draft
> to mix (quite a few) citation errors that nobody seems to
have spotted before.
> Please review this document very thorougly ..
Two problem areas Mike and I picked up
i Section 5.1.8 - 'Profiling Rule (a): Receipts for
reception awareness' states the following
If this element is not used, then eb:Receipt MUST be
empty.
However, the schema definition for Receipt is as follows
<xsd:complexType name="Receipt">
<xsd:sequence>
<xsd:any namespace="##other"
processContents="lax" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
with minOccurs not defined. If that is the case then
minOccurs defaults to 1.
Also see
http://www.w3schools.com/schema/schema_complex_indicators.as
p
Is this not a problem in the spec ?
ii PMode[1].Security.SendReceipt: support required
(true/false)
Should the (true/false) be there ?
This in light of 3.2
'Reception awareness error handling (REQUIRED support)'
so if consumer MSH ..SendReceipt is set to false then
producer MSH must report an error ?
And also section 3.4 bullets 2 and 3.
--
Regards
Theo
------------------------------------------------------------
---------
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_work
groups.php
------------------------------------------------------------
---------
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_work
groups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]