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:
