Meeting minutes of October 14th meeting

Erlend introduces himself. He works as software developer and architect for the Norwegian agency of public management and eGovernment (Difi). He is joining the TC as a result of processes in Difi and e-SENS where AS4 is being introduced as messaging protocol.

There are several options for handling large payloads, split and join, AS4 restart, external references and letting the business application handle it. Beside the last none is completely specified.

Pim mentions that the AS4 Restart uses the HTTP Range header in a way that is not compatible with the HTTP RFC as that defines it only for the GET method and states that the header must be ignored for other methods. The AS4 Restart would therefor not conform to the HTTP Range request specification. Pim questions whether it therefor is a good idea to define such a restart specification.

Sander explains that AS4 Restart would indeed not conform to the HTTP Range request spec but that this is also not the objective. The idea was to extend AS2 Restart to make also the Pull restartable. Therefor it also use the same HTTP Range header. Toon points out that this also has the advantage that the restart can also be implemented by a proxy without the need to change the MSH itself. As agreed during the last meeting Sander will continue work on the AS4 Restart.

The problem for both split&join and external references is that they currently do not combine with AS4. In discussion with developers and analysts from several projects the external reference option seems to be a good and probably simple solution. It however does require some additional specification/profiling. Sander will try to summarise what needs to addressed to use this option.

Sander raises a more general question whether ebMS/AS4 should be used for transferring such large files in the first place. Up to at least 2GB is no problem in standard ebMS/AS4 messaging. For larger payloads maybe other protocols are more suited for this in the first place.

Requests for the errata documents have been submitted to TC Admin. To be considered errata the changes applied to the specifications must be non-substantive. Some issue resolutions may however be considered substantive changes, for example around the type attribute of properties and encryption of a SOAP body without payloads. The TC decides to start working on the issues that are clearly non substantive and then address the more complex ones.

For handling the still open issues it is agreed that these are discussed in JIRA before the calls and that on the call the resolution can be decided upon. At least one week before each call a list of issues to decide on at the call will be sent to the list by the chairs.

Sander got a question from a customer about requirements on the number of payloads that must be included in an ebMS message. An implementor involved in the customers project stated that the ebMS specification requires that an ebMS message must include at least one payload. The project uses version 2.0 of the ebMS specifications. The TC agrees that there exists no such requirement and it should be possible to have a message without payloads. In the ebMS V3 Core Specification this is also explicitly stated in §5.2.2 (eb:PayloadInfo is optional).

ebxml-msg message