Draft meeting minutes for April 8th meeting

[Sander Fieten <sander@fieten-it.com>]

MEETING MINUTES OF EBXML MESSAGING TC MEETING 8 APRIL 2015

ATTENDANCE

Sander Fieten (chair)
Makesh Rao (chair)
Theo Kramer

Pim van der Eijk

Bram Bakx

AGENDA

Approval of previous minutes

CPA 2015 draft

Large message

Issues

Approval of previous minutes

The meeting minutes of the March 11th, February 11th and January 14th are unanimously approved.

CPA 2015 draft

Pim posted a message to the list shortly for the meeting. The message contains the output of an XSLT that transforms the CPA format to the P-Mode notation (not XML). Pim asks TC members to review and post comments. Such a stylesheet can be used to show how the CPA could be mapped to implementation specific P-Mode formats.

Bram asks what the target is for the CPA standard: is it to be the single configuration standard or to be combined with a formalized P-Mode? Pim points out the target would be that CPA is the only standard for configuration. 

Sander expresses concerns that using different names in the CPA for PMode parameter can be very confusing for users even if a mapping tool exists.

Large messages

Sander explains he has been asked by several parties about large messages. They would like to able to resume the transfer of a large message without always splitting it. This could be done by using a protocol similar to AS2 Restart and HTTP Range Request. These could be adapted to work with AS4. Other members make remarks on handling such large files, it is not only about the transfer, but also about processing it. 

An alternative approach is to use the external reference to the large payload. A additional profile could describe how such reference should be processed by the MSH. TC Members agree that this could also be a good approach for handling the large messages. This wil not directly support push but this could be solved using cloud storage. 

TC agrees to start further looking into the options. Sander will try to create a first draft. 

Issues

Sander asks if TC members are aware of implementation that bundle PullRequest with other message units. There already is issue #22 about possible issues related to such bundling and there were also issues raised by other parties. 

TC Member are not aware of implementation that use this type of bundling, so it looks like this will not be a real problem.

Attachment: smime.p7s
Description: S/MIME cryptographic signature