RE: [ebxml-msg-as4] Groups - AS4 Profile Development Draft (AS4-Deployment-Profile-Draft-95.doc) uploaded

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

Hello,

Here are some written review comments:

#1
Section 2.1.1 Pull authorisation, Security section. This mentions two
options to secure the Pull signal.  In a single-hop context, a third option
could be to use SSL/TLS client authentication and authorize based on the
established client identity.  

#2
Section 2.1.1 Authorization option 1 is based on a separate WSS header
targeted at an actor with value "ebms". This is from the core so it probably
shouldn't change, but in SOAP 1.2 similar values are expressed as qualified
URIs with values like "http://www.w3.org/2003/05/soap-envelope/role/next"; or
"http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver";, so would
something like "http://docs.oasis-open.org/ebxml-msg/ebms/3.0/ns/..."; be
more appropriate?

#3
Section 2.1.1 "if the SSL protocol is used" --> "if transport level security
is used"
The core spec references TLS 1.0 (which supersedes SSL) and IPsec.   
(Also in other parts of the spec)  

#4
Section 3.1. Why the limitation to GZIP?  Most toolkits will support
multiple compression mechanisms, and they have different pros/cons that a
community could profile further.

#5
Related comment on Payload PartProperties:
Would it be useful to have a convention to include the original filename
too?

	<eb:Property name="FileName">order123.xml</eb:Property> 

This information may also be in the MIME Content-Disposition, but some
products don't provide access to MIME part information at the SOAP/ebMS
layer and it may be more convenient to include it in the SOAP/ebMS header.

#6
Section 4.1.2
"When sending a Receipt for this MEP, a Sending MSH conforming to this
profile SHOULD NOT bundled the Receipt with any other ebMS message header or
body."
Should this be (assuming "Sender", "Receiver" at ebMS level where the
receiver is the one that pulls):
"When sending a Receipt for this MEP, a Receiving MSH conforming to this
profile SHOULD NOT bundle the Receipt with any other ebMS message header or
body."

But, is this restriction on bundling consistent with 2.1.1 "ebMS MEP", which
does seem to allow for this level of bundling?

#7
Section 4.1.8
"reciept" --> "receipt"

#8
Section 4.2.3
Refers to SSL authentication, but does not provide P-mode parameters for
specific certificates that are used/trusted.
Section 4.2.6 allows the community to specify trusted CAs, but some
applications may want to control the specific certificates or use
self-signed certificates. So a fine-grained control as is done at WSS
configuration would make sense.

#9
Section 4.2.4
"contains a composite string"  
It would be cleaner to have separate P-mode parameters for these properties.

#10
Section 4.2.6 (b)
Why are TLS encryption algorithms a "usage agreement" rather than part of
the profile? 
It seems important for technical interoperability of products.

Pim

-----Original Message-----
From: jdurand@us.fujitsu.com [mailto:jdurand@us.fujitsu.com] 
Sent: 09 January 2009 00:50
To: ebxml-msg-as4@lists.oasis-open.org
Subject: [ebxml-msg-as4] Groups - AS4 Profile Development Draft
(AS4-Deployment-Profile-Draft-95.doc) uploaded

V0.95:
- Fixed all comments summarized in email 12/30 ("comments on 0.9")
- Cleaned-up the bundling option for Receipts both on the conf profile side
and the usage profile side.
- Added the duplicate detection feature as required (see section 3), and
added PMode config parameter for it in the Usage profile section.
- Added requirement for "MissingReceipt" new error code.
- Added a small section that summarizes the semantics of Receipts in AS4.

 -- Mr Jacques Durand

The document revision named AS4 Profile Development Draft
(AS4-Deployment-Profile-Draft-95.doc) has been submitted by Mr Jacques
Durand to the ebXML Messaging Services AS4 SC document repository.  This
document is revision #3 of AS4-Deployment-Profile-Draft-07b.doc.

Document Description:
v0.7b:
- Added some details to the Section 3.1 about the Compression feature.
V0.8
- Added compression profiling (section 3.1)
- updated authorization for light client (table 2.2.1, Security)
V0.9:
- added the proposed update for Compression indicator (additional
eb:Property, in addition to the gzip content type)
- reorganized completely Section 4 (Deployment Profile now renamed Usage
Profile) with two major subsections: (4.1 AS4 Usage Rules, 4.2 AS4 Usage
Agreements).
- enhanced the description of major agreement options (in new 4.2), and
referenced appropriate PMode parameters.
- also added additional PMode parameters needed to control Delivery
Awareness (Section 3).
V0.95:
- Fixed all comments summarized in email 12/30 (&quot;comments on
0.9&quot;)
- Cleaned-up the bundling option for Receipts both on the conf profile side
and the usage profile side.
- Added the duplicate detection feature as required (see section 3), and
added PMode config parameter for it in the Usage profile section.
- Added requirement for &quot;MissingReceipt&quot; new error code.
- Added a small section that summarizes the semantics of Receipts in AS4.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=30589

Download Document:  
http://www.oasis-open.org/committees/download.php/30589/AS4-Deployment-Profi
le-Draft-95.doc

Revision:
This document is revision #3 of AS4-Deployment-Profile-Draft-07b.doc.  The
document details page referenced above will show the complete revision
history.


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration