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