[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
Some further comments No reference is made to MPC in schedule 5. I recommend this is included as it is not advisable to use the default MPC for pulling from multiple partners Schedule 4 section 2.5.2 table 3 lists default services for member contribution management (registration, contributions etc) but I see no corresponding set of services for rollover management. On 31 Oct 2012, at 1:14 PM, Pim van der Eijk wrote: > 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: 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. > > 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: ebxml-msg-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: ebxml-msg-help@lists.oasis-open.org >> > -- Regards Theo
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]