Range MLA

 Problem statement

As mentioned in WG mandate:
The Message Level Acknowledgement (MLA) BIS (working title) is a message necessary making it able to C3 to inform C2 about the status of the received document. This enables C2 to take appropriate action.
Currently there is a Message Level Response (MLR) BIS available to provide parts of the needed functionality. However, these are not a solution to capture all required functionality.
There is a clear distinction between the MLA, to be used between C3-C2, and IMR, used between C4-C1.

 Research insights

20221222 Jelte Jansen: As the mandate states: "Developing an MLA BIS that meets the needed requirements.". However, I don't think I've actually seen any requirements, and from talks at the kickoff meeting I don't think we all have the same requirements in mind. My initial thoughts for requirements were framed around what I think is missing from the MLR specification, namely: - The MLR specification does not define a method to signal that you can   receive and process these messages (as C2) - The MLR specification does nog define a method to signal where these   messages should be sent (as C2) - The only class of errors to report in the MLR is validation errors,   and if people implemented their C2 correctly, these should not be an   issue - The MLR specification leaves sending MLRs optional, and many people   would opt to only sent errors, not sucess messages The last part is not a problem in and of itself, but together with the limit to validation errors only, it is really only useful to tell some C2 that they are not following the infrastructure agreements. IMHO this should be possible on both the transport level (if you validate synchronously, just not with a 500 error) and with an MLA message (when you validate asynchronously), but more importantly, this is not nearly enough when you look at where the full chain breaks and documents get lost, which is often between C3 and C4, and for entirely different reasons than validation errors. This leads me to another requirement, one of scope: the scope of the MLA should be such that it can report issues that are not covered by transport errors, or by the Invoice Response. I fully realize this is somewhat of a circular dependency, as their scopes should be such that they cover what the MLA does not. So as a starter point, this leads me to (at least) the following requirements for the MLA: - the MLA is sent between C3 and C2 - it should be specified how to signal support for MLA (as C2) - it should be possible to signal where the MLA should be sent (as C2) - the MLA should clearly convey what C2 (or C1) should do with the   information - the MLA should cover both processing issues at C3 itself, and   delivery issues to C4 (including whether C4 is not accepting the   delivery on a technical level) I personally have some additional and more specific requirements for some of these, but some of those depend on later discussions, so for this topic I will for now leave it at that.

I originally thought addressing and support signaling for MLA were two
separate topics as well, but they are too intertwined to discuss
separately, as in almost every case, simply signaling where an MLA can
be sent implies that the MLA is supported by the sender. The MLR specification itself leaves signaling and addressing out of scope, and I think this is one of the things we need to fix for the MLA.

I think there's three places to signal where an MLA could be sent:

1. In C1's SMP publication (assuming C1 is also a C4)

2. In some, yet to determine, SMP publication of C2 itself

3. In the communication between C2 and C3 (either the SBD Envelope or
   in the AS4 message)

Each of these has their own advantages and drawbacks, so let me explain
them a bit further, and discuss those:

1. In C1's SMP publication

This is currently the way to signal MLR support, and we can choose to
do the same for the MLA. It is generally assumed that every sender on
the network can also receive, so it is a logical step to simply publish
support for the MLR there as well. If this support is signaled, the SMP
publication contains the necessary information on the MLA, just as for
any other document type.

Advantages:

• signaling is mostly in-place already. We do need to determine whether
  MLA's need a separate document type for every process they can occur
  in, or that they are applicable to all processes

• there can be multiple 'MLA' endpoints for a service provider

Disadvantages:

• the SMP entry may not be controlled by C2; it could be an entirely
  different service provider that may not cooperate very well, and
  there are no policies on cooperation here, let alone protocols for
  automation.

1. In some, yet to determine, SMP publication of C2 itself

The example I heard here was to use the Peppol Seat ID to publish an
SMP entry with the necessary information. So for example, for Seat ID
we add the schemeID 9988, and, as a C2 you'd publish an SMP entry
9988:POP006789 fwhere C3s can send their MLAs.

Advantages:

• C2 has full control over their entry, and they are not dependent on
  other providers.

Disadvantages:

• Only one MLA address per service provider. This would mean that they
  either need to have only a single access point, or they need a
  central access point which relays the MLA's back to the actual access
  points, which would then require a central system that has knowledge
  of all the SP's transactions in real-time.

1. In the communication between C2 and C3

Both the SBD Envelope and the AS4 UserMessage have room for additional
information. In the case of the SBD Envelope, one could add a new scope
field (e.g. "MLA_TO") with a peppol identifier determined by C2. In the
AS4 header, this could go in a messageProperty field.

This could even be a direct endpoint URL instead of a peppol
identifier, though in that case some fixed assumptions would need to be
made about transport and security (which would be 'use the ones used
for this message').

Advantages:

• Most flexible, as it can be set per access point, per sender, or
  should it be necessary, per message even
  Disadvantages:

• Requires a specification change on either the SBD or the Peppol AS4
  Profile

These are the options I see, and if it's not clear yet, I personally
have a preference to that last one.

20230124 Ahti Allikas: that status vice (AB, RE, DL, AP…) MLR sounds very much like C3>C2 message but to be correct in here lets stick to MLA (Message level acknowledgement) message. If the syntax and semantic of MLA will eventually be exactly the same as MLR then this is only positive coincidence. I don’t see us changing MLR BIS concept rather introducing MLA (and maybe let the MLR die out slowly).

 Solution hypothesis