OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] Australian Tax Office ebMS3/AS4 profile feedback from this TC

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,  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: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Sander Fieten
Sent: 30 October 2012 22:38
To: ebxml-msg@lists.oasis-open.org
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.


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:


As discussed yesterday,  I asked if consolidated our feedback by next meeting meets the schedule,  and can confirm it does.



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.




To unsubscribe, e-mail: ebxml-msg-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ebxml-msg-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]