#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)
<JD> OK.
#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.
<JD> GZIP was the mandatory compression in AS2, and
that worked well. For the sake of interop, we decided to restrict to GZIP only,
in terms of what a conforming product must support (you can have products that
support alternatives in addition).
#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.
<JD> We discussed that one quite a bit. Indeed it
is helpful to indicate this info in ebMS header, in addition to having it
in some MIME Content parameter (so this is an intended redundancy
here).
But that should remain an option, and there is no
specific processing requirement associated with this anyway, productwise. Also,
this information
So what we suggest, is to add in the Usage rules
something like:
" In case users decide to report the file name associated
with a MIME part in the ebMS header, it must follow the rules:
(a) must be done as a <property> element in
<partinfo>, with the @name = "FileName",
(b) the value of this property must be same as the file
name value in the corresponding COntent parameter XYZ."
It becomes then a user decision whether or not to use
this property (agreements section under 4.2.8 )
#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?
<JD> Not discussed yet. My $0.02:
>Should this be (assuming
"Sender", "Receiver" at ebMS level where the receiver is the one that
pulls):
Right, sending of a Receipt is not in the role of the Sending
MSH .
>But, is this restriction on
bundling consistent with 2.1.1 "ebMS MEP", which does seem to allow for this
level of bundling?
No. 2.1.1 requires for the ability to "process"
received bundled Receipts, for max interoperability. In theory that should not
be necessary.
#7
Section 4.1.8
"reciept" --> "receipt"
<JD> Sure
#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.
<JD> Not discussed yet. My $0.02: Yes we need more
PMode parameters. Can you suggest whats needed to address your
concern?
#9
Section
4.2.4
"contains a composite string"
It would be cleaner to have
separate P-mode parameters for these properties.
<JD> Not discussed yet. My $0.02: Problem is, at
this level of granularity there might be many options that are different from
one implementation to the other, and they are not really critical for AS4
interoperability. For example, an implementation will detect dups over a time
window back from present time, another one will guarantee dup check for the last
1M messages, no matter how far in the past. Same for Replay parameters: could be
controlled by timeout, by time interval * max retries, etc. Thtas why WS-RX
decided to not standardize such paraemters.
#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.
<JD> Not discussed yet. My $0.02: You mean why
aren't they part of the Conformance Profile section? The Conformance Profile
dictates what a product MUST support (or in some cases, just a SHOULD). So
far, SSL or TLS appears as out of scope of(orthogonal to) the AS4 profile:
no product requirement on using these. They still appear in the "Usage
agreement" part as a major agreement item for users to decide, and one that is
advised to be used when using Pull Authorization option #1 without other
security headers.