Hello,
Good comments from Sander and Theo. Here are
some additions:
Section 2, the AS4 profile reference could be updated to
the more recent "Candidate OASIS Standard" version, or more generally to
the latest release at http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/.
Section 3.2, there is a defined default role in Core
Spec 5.2.2.3, but I would think that the profile and business
processes should be organized so that there are always specific roles.
Section 3.2.3, my personal preference would be to not
include a Pmode ID type attribute in ebMS messages but to infer Pmodes from
ebMS header attributes.
In (the second) section 4.2 there is a reference to
"Username/password based security": this is referencing WS-Security
UsernameToken (rather than e.g. HTTP authentication) as mentioned in the
appendix, it may be worthwhile to be explicit on this here. It is
also probably worth mentioning that X509-based security is explicity not
required.
Section 4, none of the profiles use WS-ReliableMessaging
or WS-Reliability, which is good but could perhaps be stated
explicitly. (AS4 does not strictly prohibit use of WS-RM, although
it clearly proposes the AS4 reliable messaging features as the better
option).
Appendix, not sure what the purpose of a default Pmode
ID is, especially if there will be distinct pmodes for various business actions
and parties. Also see above.
Appendix, my recommendation for use of the UsernameToken
would be to include the Digest, Nonce, and Created options. These do not
seem hard to implement even in low-end products, so requiring them in
products is not a barrier for vendors.
Appendix, the default
parameters for retries only support retries up to 3 minutes. To be
more robust, I would recommend retries for much longer intervals,
if the business process allows this.
Appendix 4, JoinInterval, it may be safe to set
this to a really high value. If this feature is used to transfer
multi gigabytes messages, then that transfer probably does not fail to fail if
it does not succeed in an hour.
From:
[mailto:] On Behalf Of Sander
Fieten
Sent: 30 October 2012 22:38
To:
Subject: Re: [ebxml-msg] Australian Tax
Office ebMS3/AS4 profile feedback from this TC
Hi all,
I am also travelling tomorrow during the call and therefor not able to
join. I also reviewed the document and these are my remarks:
Second paragraph on eb:AgreementRef in section 3.2.3: I would add a
reference to chapter 5 where these default agreements are explained;
In the last paragraph on eb:AgreementRef the last sentence is unfinished.
Problably "Agreement" should be added;
In section 3.2.5 (Part properties): Why is a property defined for
identification of the part? Are there specific requirement the href attribute
of PartInfo can not be used?
There are two sections numbered 4.2
Section 4.2 Mulit-hop: As profiles here are based on AS4 I suggest to
refer to chapter 4 of the AS4 profile explaining how to implement multi-hop in
an AS4 context
For all sub sections of 4.2 I think the conformance clause is quite and
unnecessarily complex. I think requiring support for a specific conformance
clause from chapter 6 of the AS4 profile combined with the multi-hop clause is
specific enough and does not require reference to chapter 2
Section 4.2.1 : Just a remark that this profile puts extra requirements on
the edge intermediaries because they have to keep connections open to be able
to deliver the response;
Section 4.2.1 : As currently stated conforming clients must support
pulling as this is a requirement from the AS4 Light Client Conformance Clause.
The required conformance is equal to that of section 4.2.2. I think an
exception for pulling is missing here
In the first sentence of 4.3.1 should "receipt" be "receipting"? Same
applies to first sentence of 4.3.2
I assume the sentence "However, support for one-way pull as responding
partner is NOT REQUIRED." implies that a conforming MSH must be able to
receive responses either on the back-channel of a request (not necessarily
synchronously) or by pulling it, but it does not need to support pull
to sent the responses? Some clarification could be helpful
In chapter five generic PMode.ID are used. However each message exchange
has its own PMode and this ID is used to identify a specific PMode, i.e.
message exchange. Therefor I would think using one generic PMode.ID is not
possible.
Regards,
Sander
On Oct 30, 2012, at 10:44 , Theo Kramer wrote:
I will be traveling on Wednesday evening so will unfortunately not be
able to attend. Please note the following input from my side.
Aus
AS4 SPR_00335171_Attach7 (Schedule 5)
3.2. This refers to Default
Role in core spec which I do not see ?
Appendix 2 -
Security.SendReceipt.ReplyPattern is set to "Callback" for the light profile ?
This implies the light profile MSH having a separate http[s] listener active
which is beyond the scope of the light client... Should this not be
"Response".
General comments/questions
The November 2
public comment deadline is tight. I anticipate further issues on the schedules
to arise during implementation
I see no reference on requirements
for schema validation for payloads ? Does that imply that MSHs must not
validate payloads ?
I see no availability of example (instance)
messages or associated schemas in the schedules. Will these be made available
?
PS - bcc'd Michael
On 18 Oct 2012, at 9:10 AM, Pim van der
Eijk wrote:
Hello,
As discussed yesterday, I asked if
consolidated our feedback by next meeting meets the schedule, and can
confirm it does.
Pim
-----------
Hi Pim.
Public consultation closes Friday 2nd November so
timing should work well. In any event, we’d welcome the TC feedback
regardless. Clearly we want the documents to reflect a correct application
of the standard.
Regards
Michael
--
Regards
Theo
---------------------------------------------------------------------
To
unsubscribe, e-mail:
For
additional commands, e-mail:
