Change Request: Identifying message formats in headers #137
Labels
fspiop-change-request
A change request for the FSPIOP API
ISO-20022-api-change-request
Change requests for the ISO 20022 API
Open API for FSP Interoperability - Change Request
Table of Contents
1. Preface
___This section contains basic information regarding the change request.
1.1 Change Request Information
| Requested By | Michael Richards, MLF |
| Change Request Status | In review ☒ / Approved ☐ / Rejected ☐ |
| Approved/Rejected Date | |
1.2 Document Version Information
2. Problem Description
___2.1 Background
At present, the Accept parameter in the message header represents the API version that the sender of a message would like to use. This enables version negotiation between participants, and is currently defined here.
The Accept parameter is structured in the following way:
For example: Accept: application/vnd.interoperability.transfers+json;version=1
When we consider the implementation of message content based on ISO 20022 alongside one based on FSPIOP, we shall need to consider whether the structure of the Accept parameter needs to be changed to specify the structure of the message content; and, if so, how this should be done.
2.2 Current Behaviour
The current structure of the Accept parameter does not allow for distinctions of message structure.
Since the resource type is currently used to allow participants to support different versions of individual resources (for instance, it would allow a DFSP to support version 1.1 of PISP and version 2 of transfers), using this part of the parameter to define the structure of the message content would remove this flexibility.
2.3 Requested Behaviour
There are basically two approaches:
Changing the structure of the Accept parameter would require changes to the ways in which DFSPs and the switch evaluate the validity of a message.
3. Proposed Solution Options
___The text was updated successfully, but these errors were encountered: