Participants and absents

Chair

Hans Berg (Deactivated) as eDelivery Community Leader

Elected members (with voting right)

~~Kristiansen, Olav Astad <Olav.AstadKristiansen@difi.no>~~

Risto Collanus (Maventa)

Philip Helger (BRZ Austria)

Bård Langöy (Pagero) (not present part 1, 10.00-10.40)

Guests (without voting right)

Jerry Dimitriou (OpenPEPPOL Operating Office)

Agenda

Discussion regarding AS2 v.1.3 and the input from Jerry Dimitriou regarding wether to introduce a new transport profile id or not.

Information items

Input from Jerry Dimitrou:

Regarding the use of a new identifier for the new AS2 spec and the current proposed migration process, the problem is on the original signed document which is submitted (the change to RFC 5652). The described migration process without the change of the identifier might be feasible if the only thing changed was the mic algorithm of the MDN. However, it does not take into account that the submitted message MUST be signed with using SHA-256 algorithms following RFC 5652.

Assuming that we are in the transition period using the same identifier for the new specification and using the headers as it was described in TICC, the following will happen:

C2 now supports SHA-256 signing, and sends the AS2 message signed with SHA-256.
C3 is not supporting yet SHA-256, and thus rejects the message, although the correct identifier is used.

A more explicit transition process including new transport profile identifier (such as 'busdox-transport-as2-ver2p0') for the new AS2 profile could work smoother:

C3, not supporting yet SHA-256, is publishing only the old AS2 Protocol identifier
C2, supporting SHA-256, first checks the SMP if C3 supports SHA-256. It gets a negative response and makes second query using the original, mandatory during the transition period, AS2 protocol identifier. No message is rejected.

Alternatively:

C3, is now ready to support SHA-256 and is making a new registration entry in the SMP.
C2, supporting only SHA-1, first checks the SMP if C3 supports SHA-1 and gets the original, mandatory during the transition period, AS2 protocol identifier. No message is rejected.

After the transition period, the submission APs will only check for the new identifier, so any stalled APs will not be discoverable any more (Less error rejections also after the transition).

Also, from an organizational perspective, since the new AS2 protocol spec is backwards incompatible with current AS2 spec, a different protocol version will clearly denote that. As a side effect, we will also have the DEPRECATED flag on the codelist, making it clear that this is no longer used and that a new incompatible specification now is in use.

Summary

Migration process

Pros

Cons

Keep existing transport profile id

V1: required to receive

V2: migration period without changing the ID

Support for receiving documents with the new AS2 profile at date X. Forbidden to send with the new AS2 profile at this stage.
Support for sending with the new AS2 profiles at date Y (Y > X).
Mandatory to only send and receive with the new AS2 profile after date Z (Z > Y).

Less effort for SPs

More failed transactions during the transition phase
Hard to get an overview of which APs that support the new AS2 profile.

New transport profile id

Remove/deprecate old transport profile id at a certain date/time
Assign new Transport Profile ID to all endpoints/participants after previous step has been performed.

More explicit and more control of who are supporting the new transport profile id
Less failed transactions during the transition phase

More effort for SPs with SMP metadata registrations

SMP providers should

Remove old transport profile id at a certain date/time
Assign new Transport Profile ID to all endpoints/participants after previous step has been performed.

To-do’s

Include the new transport profile id 'busdox-transport-as2-ver2p0'
Include http/1.1 (as in v.1.3) (see TICC-69 - Getting issue details... STATUS )
Member review (until March 10)
Comment resolution (until ≈ March 17)
Release PEPPOL AS2 profile v.2.0 specification
Decide a migration start date / end date for service providers
Propose the above steps to the MC for approval

Decisions

TICC CMB will draft a v.2 of the AS2 profile that is based on 1.3 but adding a new transport profile id (busdox-transport-as2-ver2p0)

Action items

Philip Helger to draft a v.2 of the AS2 profile as suggested above.

Attachments

	File	Modified

No files shared here yet.

Browser not supported