RE: [ebxml-msg] Groups - AS4-Profile-csd04-wd-13.odt (AS4-Profile-csd04-wd-13.odt) uploaded

["Pim van der Eijk" <pvde@sonnenglanz.net>]

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