21 MCData Message Store

24.2823GPPMission Critical Data (MCData) signalling controlProtocol specificationRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

21.1 General

This clause defines procedures for communication between the MCData message store client and the MCData message store function as well as the MCData server and the MCData message store function as specified in clause 7.13.3 of 3GPP TS 23.282 [2].

Additionally, this clause defines procedures for communication between the Message notification client and the MCData notification server as well as the MCData message store function and the MCData notification server as specified in clause 7.13.3 of 3GPP TS 23.282[2].

The communication between the MCData message store client and the MCData message store function as well as between the Message notification client and the MCData notification server shall use HTTP over TLS as specified in annex A of 3GPP TS 24.482 [24].

The hostname of the MCData message store is configured in the MCData user profile configuration document as specified in clause 10.3 of 3GPP TS 24.484 [12].

The hostname of the MCData notification server is configured in the MCData service configuration document as specified in clause 10.4 of 3GPP TS 24.484 [12].

The MCData message store function shall act as an HTTP server as defined in annex A of 3GPP TS 24.482 [24].

The MCData message store client and the Message notification client in the role of an HTTP client shall include the MCData access token (with the "Bearer" authentication scheme) in the Authorization header field of an HTTP request as specified in 3GPP TS 24.482 [24].

The HTTP server (i.e. the MCData message store and the MCData notification server) shall validate the MCData access token as specified in 3GPP TS 24.482 [24].

NOTE 1: In procedures for communication between the MCData message store client and the MCData message store function as well as communication between the Message notification client and the MCData notification server, the MCData ID which is the identity of the MCData user is part of MCData access token as specified in 3GPP TS 24.482 [24]. Additionally, the MCData ID can be used as the value for userId variable while generating the HTTP request URL.

NOTE 1A: In procedures for communication between MCData server and MCData message store function, the MCData ID which is the identity of the MCData user is used as the value of the resource URL variable, "boxId" as specified in clause 5.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

The interface between the MCData message store client and the MCData message store function (i.e. MCData-7) as well as the interface between the MCData server and the MCData message store function (i.e. MCData-8) shall be based on the RESTful API as specified in OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

The interface between the Message notification client and the MCData notification server (i.e. MCData-10) shall be based on the RESTful API as specified in OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76].

the MCData message store function uses HTTP POST method to push notifications to the MCData notification server (i.e. MCData-11) at a CallBack URL provided by the MCData message store client during notification subscription creation procedure (as defined in the following clauses).

The HTTP communications (i.e. RESTful API invocations) between the MCData server and the MCData message store function (i.e. MCData-8) as well as between the MCData message store function and the MCData notification server (i.e. MCData-11) are authenticated/authorizated as per security mechanisms described in 3GPP TS 33.180 [26].

NOTE 2: Procedures defined for communication between the MCData message store client and the MCData message store function as well as the MCData server and the MCData message store function in the following sections reference clause 6 "Detailed specification of the resources" of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]. Additional information related to RESTful resources, data types and sequence diagrams are found in clause 5 and JSON examples in appendix D of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

NOTE 3: Procedures defined for communication between the Message notification client and the MCData notification server in the following sections reference clause 6 "Detailed specification of the resources" of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]. Additional information related to RESTful resources, data types and sequence diagrams are found in clause 5 and JSON examples in appendix D of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76].

21.2 MCData message store functions and client procedures

21.2.1 Object retrieval procedure

21.2.1.1 Message store client procedures

To retrieve the object from MCData message store, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP GET request as specified in clause 6.2.3 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP GET request towards the message store function.

Upon receipt of an HTTP response, the message store client shall follow the procedure as described in clause 6.2.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.1.2 Message store function procedures

Upon receipt of the HTTP GET request from the client, as per clause 21.2.1.1, with the Request-URI identifying a resource in the MCData message store, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP GET request by following the procedures described in clause 6.2.3 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation (e.g. if the object identified by the Request URI was successfully found, it is returned in the HTTP response).

21.2.2 Object search procedure

21.2.2.1 Message store client procedures

To search for information about a selected set of objects in the MCData message store, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.8 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.8.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request, which includes a "SelectionCriteria" data structure, towards the message store function.

Upon receipt of an HTTP response, the message store client shall follow the procedure as describe in clause 6.8.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.2.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.2.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.8.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response, containing the objects matching the SelectionCriteria, towards the message store client.

21.2.3 Update object(s) procedure

21.2.3.1 Message store client procedures

To update object(s) in the MCData message store, the message store client, acting as an HTTP client, shall either follow the procedure described in clause 6.3 or 6.4, for individual object update, or 6.11 for bulk update of objects, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall either generate an HTTP PUT request as specified in clause 6.3.4, 6.4.4, for individual object update, or an HTTP POST request, as specified in clause 6.11.5, for bulk update of objects, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66], as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP PUT request, for individual object update, or the HTTP POST request, for bulk update of objects, towards the message store function.

Upon receipt of an HTTP response, the message store client shall either follow the procedure as described in clause 6.3.2, 6.4.2 for individual object update response, or clause 6.11.2 for bulk update of objects response, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.3.2 Message store function procedures

Upon receipt of the HTTP PUT or the HTTP POST request from the client, as per clause 21.2.3.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) if the received request is an HTTP PUT, shall process the HTTP PUT request for individual object update by following the procedure described in clauses 6.3.2 or 6.4.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

b) if the received request is an HTTP POST, shall process the HTTP POST request by following the procedure described in clause 6.11.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] for bulk update of objects; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the update operation.

21.2.4 Delete stored object(s) procedure

21.2.4.1 Message store client procedures

To delete object(s) in the MCData message store, the message store client, acting as an HTTP client, shall either follow the procedure described in clause 6.2, for individual object delete, or clause 6.12 for bulk delete of objects, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall either generate an HTTP DELETE request as specified in clause 6.2.6, for individual object delete, or an HTTP POST request as specified in clause 6.12.6, for bulk delete of objects, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66], as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP DELETE request, for individual object delete, or the HTTP POST request, for bulk delete of objects, towards the message store function.

Upon receipt of an HTTP response, the message store client shall either follow the procedure as described in clause 6.2.2, for individual object delete response, or clause 6.12.2, for bulk delete of objects response, of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.4.2 Message store function procedures

Upon receipt of the HTTP DELETE or the HTTP POST request from the client, as per clause 21.2.4.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) if the received request is an HTTP DELETE, shall process the HTTP DELETE request for individual object delete by following the procedure described in clause 6.2.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

b) if the received request is an HTTP POST, shall process the HTTP POST request by following the procedure specified in clause 6.12.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] for bulk delete of objects; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the delete procedure.

21.2.5 Void

21.2.5A Deposit an object procedure

21.2.5A.1 MCData server procedures

To deposit an object of an MCData user in the MCData message store, the MCData server acting as an HTTP client shall follow the procedure described in clause 6.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.1.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall set the boxId of the resource URL as specified in clause 6.1.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] to MCData ID which is the identity of the MCData user;

c) shall include a valid access token in the HTTP Authorization header as described in 3GPP TS 33.180 [26]; and

d) may include the query parameter "retrieveFile" in the Request URI with its value set to:

i) "No" if the MCData store is not required to retrieve the file from MCData content server; or

ii) "Yes" if the MCData store is required to retrieve the file from MCData content server and to store it locally in the MCData message store; and

NOTE: Including the retrieveFile query parameter with the value "Yes" is the same as if the retrieveFile query parameter is absent.

2) shall send the HTTP POST request towards the message store function.

Upon receipt of an HTTP response, the MCData server shall follow the procedure described in clause 6.1.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.5A.2 Message store function procedures

Upon receipt of the HTTP POST request from MCData server, as per clause 21.2.5A.1, with a Request-URI identifying a resource on the MCData message store, the message store function acting as an HTTP server:

1) shall validate the access token received in the Authorization header of the request as specified in 3GPP TS 33.180 [26];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.1.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; with the following clarification:

i) if the query parameter "retrieveFile" is set to "Yes" or if it is absent from the request URI, the message store function shall retrieve the file pointed to by the object’s payloadPart URL(carried within the HTTP POST request body), store the file in the user’s message storage area and update the object’s payloadPart URL accordingly; and

3) shall generate and send the HTTP response towards the MCData server indicating the result of the deposit an object operation as per clause 6.1.2 of the OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.6 Object and folder copy procedure

21.2.6.1 Message store client procedures

To copy object(s) and/or folder(s) to a destination folder in the MCData message store, the message store client, acting as an HTTP client, shall follow the procedure described in clause 6.18 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.18.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] with following clarifications:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request identifying the target folder and the source objects(s) and/or folder(s) for copying operation towards the message store function.

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.18.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.6.2 Message store function procedures

Upon receipt of the HTTP POST from the client, as per clause 21.2.6.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.18.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and copy to the target folder the requested source object(s) and/or folders(s); and

3) shall generate and send a HTTP response towards the message store client indicating the result of the operation.

21.2.7 Deleting a folder procedure

21.2.7.1 Message store client procedures

To delete a folder in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.14 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP DELETE request as specified in clause 6.14.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP DELETE request identifying the folder to be deleted towards the message store function.

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.14.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.7.2 Message store function procedures

Upon receipt of the HTTP DELETE request from the client, as per clause 21.2.7.1, with the Request-URI identifying the folder in the message store to be deleted, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP DELETE request by following the procedures described in clause 6.14.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation.

21.2.8 Create a folder procedure

21.2.8.1 Message store client procedures

To create a folder in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.13 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.13.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send towards the message store function the HTTP POST request identifying the target folder where the new folder is to be created.

Upon receipt of a HTTP response, the message store client should follow the procedure as described in clause 6.13.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.8.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.8.1, identifying the new folder to be created, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.13.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and create the requested folder; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation.

21.2.9 void

21.2.10 Moving object(s) and folder(s) procedure

21.2.10.1 Message store client procedures

To move object(s) and/or folder(s) to a destination folder in the MCData message store, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.19 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.19.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request, identifying source objects and/or folder(s) to be moved to the designated destination folder, towards the message store function.

Upon receipt of a HTTP response, the message store client shall follow the procedure as described in clause 6.19.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.10.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.10.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.19.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and perform the move operation; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation.

21.2.11 Folder search procedure

21.2.11.1 Message store client procedures

To search for information about a selected set of folder(s) in the MCData message store, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.16 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.16.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request, which includes a "SelectionCriteria" data structure, towards the message store function.

Upon receipt of a HTTP response, the message store client should follow the procedure as described in clause 6.16.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.11.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.11.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.16.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response, containing the folders matching the SelectionCriteria, towards the message store client.

21.2.12 Void

21.2.12A Create a subscription to notifications procedure

21.2.12A.1 Message store client procedures

In order for the message store client to keep its local store in sync with the MCData message store, it needs to receive notifications about changes in the message store. For this purpose, the message store client would need to subscribe to notification from the message store. Synchronization using subscriptions and notifications is described in clause 5.1.5.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

To create a subscription to notifications about changes in the message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.20 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.20.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function; and

b) shall include a valid MCData access token in the HTTP Authorization header; and

2) shall send the HTTP POST request towards the message store function.

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.20.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.12A.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.12.1, with a Request-URI identifying a resource on the message store, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.20.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and create the requested subscription; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation as per clause 6.20.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.13 Void

21.2.13A Delete a subscription to notifications procedure

21.2.13A.1 Message store client procedures

To delete / cancel a subscription and stop corresponding notifications about changes in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.21 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP DELETE request as specified in clause 6.21.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function; and

b) shall include a valid MCData access token in the HTTP Authorization header; and

2) shall send the HTTP DELETE request identifying the subscription to be deleted towards the message store function.

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.21.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.13A.2 Message store function procedures

Upon receipt of the HTTP DELETE request from the client, as per clause 21.2.13.1, with a Request-URI identifying the subscription resource on the message store, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP DELETE request by following the procedures described in clause 6.21.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and delete the requested subscription; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation as per clause 6.21.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.14 Void

21.2.14A Update a subscription to notifications procedure

21.2.14A.1 Message store client procedures

A client may update its subscription to notification in order to:

1) extend the life of the subscription;

2) restart the notification stream from where it left off.

Synchronization using subscriptions and notifications is described in clause 5.1.5.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]

To update a subscription to notifications about changes in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.21 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.21.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

2) shall send the HTTP POST request towards the message store function.

Upon receipt of an HTTP response, the message store client should follow the procedure described in clause 6.21.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.14A.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per bclause 21.2.14A.1, with a Request-URI identifying a subscription resource on the message store, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.21.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] and update the requested subscription; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation as per clause 6.21.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.15 Object(s) upload procedure

21.2.15.1 Message store client procedures

To upload the object(s) to the MCData message store, the message store client acting as an HTTP client, shall either follow the procedure described in clause 6.1 for single upload or clause 6.10 for bulk upload of objects as specified in the OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in either clause 6.1.5 or 6.10.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] depending on a single object upload or bulk upload of objects as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request towards the message store function.

Upon receipt of an HTTP response, the message store client shall follow the procedure as described in clause 6.1.2 for single upload or 6.10.2 for bulk upload as specified in the OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.15.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.15.1, with a Request-URI identifying a resource on the MCData message store, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in either clause 6.1.5 or 6.10.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] depending on a single object upload or bulk upload of objects; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the upload operation.

21.2.16 Synchronization notifications procedure

21.2.16.1 Message store function procedures

To send notifications about changes in the MCData message store using the message store function, the MCData message store, acting as an HTTP client shall follow the procedure described in clause 6.22 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP POST request as specified in clause 6.22.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field using the callback URL which was previously provided by the message store client in its corresponding subscription creation request as specified in clause 21.2.12A; and

b) shall send the HTTP POST request towards the callback URL provided by the client.

Upon receipt of an HTTP response, the message store function should follow the procedure as described in clause 6.22.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.16.2 Message store client procedures

If the callback URL in the HTTP POST request (clause 21.2.16.1) points to the message store client then upon receipt of the HTTP POST request from the MCData message store, as per clause 21.2.16.1, the message store client acting as an HTTP server (for such an in-band connection as described in clause 7.13.3.17.2 of 3GPP TS 23.282[2]):

1) shall process the HTTP POST request by following the procedures described in clause 6.22.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

a) either use the notification content and the reported "restartToken" and "index" as specified in clause 5.1.5.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] to have the client’s local message store updated accordingly; or

b) use the notification as a trigger to subsequently search the MCData message store for the list of changes as specified in clause 21.2.17; and

2) shall generate and send an HTTP response towards the message store function indicating the result of the operation as per clause 6.22.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

NOTE: The notifications about changes in the MCData message store can be used by the message store client to synchronize its local message store with the MCData message store in two distinguished ways which are listed in sub-bullets "a" and "b" above.

If however, the Message store client is not using an in-band connection with the MCData message store to receive notifications and has instead created a notification channel with the MCData notification server (see clause 7.13.3.17.3 of 3GPP TS 23.282[2]) as described in clause 21.2.19, then the message store client shall not follow the procedure in this clause and instead follow the procedure described in clause 21.2.22 "Open notification channel" in order to start receiving the notifications (about changes in the message store).

21.2.16.3 MCData Notification server procedures

If the callback URL in the HTTP POST request, as described in clause 21.2.16.1, points to the MCData Notification server then upon receipt of the request from the MCData message store, the MCData notification server acting as an HTTP server as per clause 7.13.3.17.3 of 3GPP TS 23.282[2]:

1) shall process the HTTP POST request; and

2) shall make the notifications available to the message notification client (and hence the message store client) through the associated channel which was previously created and as need be opened (see clause 21.2.19 and clause 21.2.22).

21.2.17 Search-based synchronization procedure

21.2.17.1 Message store client procedures

To search for changes (e.g. newly created objects, recently deleted objects, etc) in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 21.2.2.1 with the following clarification:

1) shall use the search criterion of "CreatedObjects", "VanishedObjects" or "Flag" in the HTTP POST request as specified in clause 5.1.5.2 and 5.4.2.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] in order to retrieve from the MCData message store the list of the newly created object, recently deleted object and/or changes to flags respectively.

21.2.17.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.17.1, the message store function acting as an HTTP server shall follow the procedure described in clause 21.2.2.2 with the following clarification:

1) if search criterion in the HTTP POST request is set to "CreatedObjects", then the HTTP POST, response shall include a "creationCursor" as specified in clause 5.3.2.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.18 Retrieve content of a given folder procedure

21.2.18.1 Message store client procedures

To retrieve the content of a given folder identified by its folder ID in the MCData message store using the message store function, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.14 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

1) shall generate an HTTP GET request as specified in clause 6.14.3 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] as follows:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) may include URI query parameter(s) necessary to control the extent of the folder’s information returned in the response; and

2) shall send the HTTP GET request towards the message store function.

NOTE: in order for the message store client to retrieve the content of the root folder, it first needs to discover its folder ID as described in clause 5.1.6 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] using Folder search procedure specified in clause 21.2.11 of the present document.

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.14.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.18.2 Message store function procedures

Upon receipt of the HTTP GET request from the client, as per clause 21.2.18.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP GET request by following the procedures described in clause 6.14.3 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response towards the message store client indicating the result of the operation as per clause 6.14.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.19 Create notification channel procedure

21.2.19.1 Message notification client procedures

To create a notification channel, the Message notification client, acting as an HTTP client shall follow the procedure described in clause 6.1 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

1) shall generate an HTTP POST request as specified in clause 6.1.5 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

a) shall set the Host header field to a hostname identifying the MCData Notification server;

b) shall include a valid MCData access token in the Authorization header; and

c) shall send the HTTP POST request towards the MCData Notification server.

Upon receipt of an HTTP response, the Message notification client should follow the procedure as described in clause 6.1.2 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76].

21.2.19.2 MCData Notification server procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.19.1, with the Request-URI identifying a resource in the MCData Notification server, the MCData Notification server acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.1.5 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]; and

3) shall generate and send an HTTP response towards the Message notification client indicating the result of the operation.

NOTE 1: A successful HTTP response includes a Callback URL and can also include a Channel URL depending on the "channelType" requested (see clause 5 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]).

NOTE 2: The Callback URL is used by the message store client in its request for creation of subscription to notifications sent towards the Message store function as described in clause 21.2.12A.

21.2.20 Delete notification channel procedure

21.2.20.1 Message notification client procedures

To delete a notification channel, the Message notification client, acting as an HTTP client shall follow the procedure described in clause 6.2 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

1) shall generate an HTTP DELETE request as specified in clause 6.2.6 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] with following the clarifications:

a) shall set the Host header field to a hostname identifying the MCData Notification server;

b) shall include a valid MCData access token in the Authorization header; and

c) shall send the HTTP DELETE request towards the MCData Notification server.

Upon receipt of a HTTP response, the Message notification client should follow the procedure as described in clause 6.2.2 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76].

NOTE: When the notification channel is deleted, the Message store client normally removes the notification subscription in the MCData Message store function as described in clause 21.2.13A.

21.2.20.2 MCData Notification server procedures

Upon receipt of the HTTP DELETE request from the client, as per clause 21.2.20.1, with the Request-URI identifying a resource in the MCData Notification server, the MCData Notification server acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP DELETE request by following the procedures described in clause 6.2.6 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]; and

3) shall generate and send an HTTP response towards the Message notification client indicating the result of the operation.

21.2.21 Update notification channel procedure

21.2.21.1 Message notification client procedures

To update a notification channel’s lifetime, the Message notification client, acting as an HTTP client shall follow the procedure described in clause 6.4 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

1) shall generate an HTTP PUT request as specified in clause 6.4.4 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

a) shall set the Host header field to a hostname identifying the MCData Notification server;

b) shall include a valid MCData access token in the Authorization header; and

c) shall send the HTTP PUT request towards the MCData Notification server.

Upon receipt of an HTTP response, the Message notification client should follow the procedure as described in clause 6.4.2 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76].

NOTE: A successful HTTP response includes the new Channel’s lifetime duration which can be used by the Message store client to update the lifetime of the notification subscription in the MCData message store function as described in clause 21.2.14A.

21.2.21.2 MCData Notification server procedures

Upon receipt of the HTTP PUT request from the client, as per clause 21.2.21.1, with the Request-URI identifying a resource in the MCData Notification server, the MCData Notification server acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP PUT request by following the procedures described in clause 6.4.4 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]; and

3) shall generate and send an HTTP response towards the Message notification client indicating the result of the operation;

21.2.22 Open notification channel procedure

21.2.22.1 Message notification client procedures

Based on the channel type created as part of the notification channel creation procedure (see clause 21.2.19. "Create notification channel"), the Message notification client would determine if and how it needs to open (interact with) the created channel for notification flow (i.e. using PULL or PUSH).

To open the notification channel for a PULL notification delivery method (i.e. created channel is of type LongPolling), the Message notification client, acting as an HTTP client shall follow the procedure described in clauses 6.3 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

1) shall generate an HTTP POST request as specified in clause 6.3.5 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] as follows:

a) shall set the Host header field to a hostname identifying the Notification server extracted from the channelURL received from the Notification server during channel creation (see clause 21.2.19. "Create notification channel");

b) shall include a valid MCData access token in the Authorization header; and

c) shall send the HTTP POST request towards the MCData Notification server using the channelURL received from the MCData Notification server during channel creation procedure (see clause 21.2.19. "Create notification channel").

Upon receipt of a HTTP response, the Message notification client should follow the procedure as described in clause 6.3.2 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]; and

1) either use the notification content and the reported "restartToken" and "index" as specified in clause 5.1.5.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] to have the client’s local message store updated accordingly; or

2) use the notification as a trigger to subsequently search the MCData message store for the list of changes as specified in clause 21.2.17;

To open the notification channel for a PUSH notification delivery method over WebSocket (i.e. created channel is of type WebSocket), the Message notification client shall follow the procedure described in Appendix I of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] and use the channelURL received from the MCData Notification server during the channel creation procedure (see clauses 21.2.19 ) to create a WebSocket connection with the MCData Notification server. The process of creating a WebSokect connection between the Message notification client and the MCData Notification server through which the MCData Notification server can send notifications to the Message notification client is not RESTful.

If the created channel is of type NativeChannel, the Message notification client, is not required to invoke the "Open notification channel" procedure as defined in this clause. See clauses 5, 5.3.13, 5.3.14 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76] for description on receiving notification over a NativeChannel.

21.2.22.2 MCData Notification server procedures

Upon receipt of the HTTP POST request (i.e. PULL notification delivery method) from the client, as per clause 21.2.22.1, with the Request-URI (i.e. channelURL) identifying a resource in the MCData Notification server, the MCData Notification server acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.3.5 of OMA-TS-REST_NetAPI_NotificationChannel-V1_0-20200319-C [76]; and

3) shall generate and send an HTTP response towards the Message notification client indicating the result of the operation. If the response is successful, it shall contain the notifications (i.e. MCData message store change events).

21.2.23 List folder hierarchy procedure

21.2.23.1 Message store client procedures

To list an existing folder’s hierarchy structure in the MCData message store, the message store client, acting as an HTTP client shall follow the procedure described in clause 6.16 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] with the following clarification(s):

1) shall generate an HTTP POST request as specified in clause 6.16.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] with the following clarifications:

a) shall set the Host header field to a hostname identifying the message store function;

b) shall include a valid MCData access token in the HTTP Authorization header; and

c) shall send the HTTP POST request towards the message store function with "SelectionCriteria" parameters "searchCriteria" and "nonRecursiveScope" absent and "searchScope" parameter either absent or containing a folder ID (for further information on "SelectionCriteria" data structure see clause 5.3.2.17 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]).

i) if "searchScope" parameter is absent, the request is to list all the subfolders recursively starting from the root folder. However, if "searchScope" parameter contains a folder ID, the request is to list all the subfolders recursively starting from the the given folder.

Upon receipt of a HTTP response, the message store client should follow the procedure as described in clause 6.16.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.23.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.23.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request by following the procedures described in clause 6.16.5 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]; and

3) shall generate and send an HTTP response, towards the message store client indicating the result of the operation. A successful "200 OK" HTTP response shall contain the "FolderReferenceList" data structure listing subfolders starting at the root folder or at the requested folder.

NOTE: For further information on "FolderReferenceList" data structure see clause 5.3.2.10 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]).

21.2.24 Retrieve file to store locally procedure

21.2.24.1 Message store client procedures

To request the MCData message store to retrieve a file associated with a given object Id from the MCData content server and store locally, the message store client, acting as an HTTP client:

1) shall generate an HTTP POST request as a custom operation associated with a stored object resource as described in clause 6.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] where:

a) the request URI shall be set to: //{serverRoot}/nms/{apiVersion}/{storeName}/{boxId}/objects/{objectId}/retrieve

NOTE: The above request URI states, the custom operation "retrieve" is performed on an object resource identified by the {objectId}. For further details on custom operations see clauses 4.4.2, 4.6.1.2 and C.4 in 3GPP TS 29.501 [79]).

b) the Host header field shall be set to a hostname identifying the message store function; and

c) a valid MCData access token shall be included in the HTTP Authorization header; and

2) shall send the HTTP POST request towards the message store function with the request containing an "Empty" data structure as described in clause 5.3.2.35 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

Upon receipt of an HTTP response, the message store client should follow the procedure as described in clause 6.2.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66].

21.2.24.2 Message store function procedures

Upon receipt of the HTTP POST request from the client, as per clause 21.2.24.1, the message store function acting as an HTTP server:

1) shall validate the MCData access token (with "Bearer" authentication scheme) received in the Authorization header of the request as specified in 3GPP TS 24.482 [24];

2) if validation is successful then

a) shall process the HTTP POST request as follows:

i) shall locate the object as identified by the {objectId} in the request URI

ii) shall use the URL value of the "href" attribute within the "payloadPart" IE of the object (see clause 5.3.2.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66]) and fetch the file from the MCData content server as described in clause 6.7, provided that the URL is pointing to a file in the MCData content server; and

iii) shall store the file locally and update the "href" attribute value of the "payloadPart" IE accordingly (i.e. to point to the locally stored file) provided the file was fetched from the MCData content server; and

3) shall generate and send an HTTP response, towards the message store client indicating the result of the operation as described in clause 6.2.2 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] with the following clarifications:

a) if the URL value of the "href" attribute within the "payloadPart" IE of the object was already pointing to a file stored locally in the MCData message store (i.e. the MCData message store did not need to fetch the file from the MCData content server), an HTTP 200 OK response containing the "Object" data structure as defined in clause 5.3.2.1 of OMA-TS-REST_NetAPI_NMS-V1_0-20190528-C [66] shall be returned; and

b) if the object is updated (i.e. "href" value of the "payloadPart" IE changed), a "changedObject" event notification (see clause 21.2.16) shall be emitted if there exists a subscription (see clause 21.2.12A) to such an event from a client.

NOTE: Returning an HTTP 200 OK response when the request is for fetching a file which has already been fetched and stored locally in the MCData message store allows proper processing of retried/duplicated requests (e.g. client retrying the same request if the response to its previous request has not arrived due to communication failure).

21.3 Control of communications storage procedures

21.3.1 General

This clause describes the MCData user control of communications storage into message store procedures for on-network.

The control of communications storage procedures provides an option for the MCData user to store the MCData communications in the MCData message store. The MCData user(s) is configured with two levels of configurations to control the storage.

1) The user profile is configured with two levels of configuration parameters to control the storage of MCData communications in the message store:

a) The user profile allows control of storage of MCData communications in the message store or not.

b) If the storage of MCData communication is allowed, the user profile allow control of storage of private communication and group communication separately.

2) During the communication, if the communication is enabled to be stored in the message store (as stated in 1 above) the user will have the choice to decide if the communication will be stored in the message store. So the user has the total control if a communication will be stored or not.

The procedures for originating MCData clients and participating MCData functions are specified in clause 21.3.

21.3.2 MCData Client procedures

21.3.2.1 General

On request from MCData user at MCData client, a request to control (i.e. to enable or disable) the storage of MCData communication into the MCData message store is initiated to the participating MCData function.

21.3.2.2 Enable communications storage into message store procedures.

Upon receiving a request from the MCData user to send a request to control (i.e., enable) the storage of MCData communications request, if the <allow-store-comms-in-msgstore> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", the MCData client shall inform the MCData user and shall exit this procedure.

Upon receiving a request from the MCData user to send a request to enable the storage of MCData communications for private and/or group, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall include a Request-URI set to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

3) shall include an Accept-Contact header field with the g.3gpp.icsi-ref media feature tag containing the value of "urn:urn-7:3gpp-service.ims.icsi.mcdata" along with the "require" and "explicit" header field parameters according to IETF RFC 3841 [8];

4) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [5];

5) shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with:

a) the <request-type> element set to a value of "store-comms-in-msgstore-ctrl-req";

b) if user want to store all the authorized MCData private communications, and if requested to store the communications, shall include <store-all-private-comms-in-msgstore> element set to a value of "true". Otherwise, if user want to store the list of MCData private communications, and if requested to store the communications, shall include <store-specific-private-comms-in-msgstore> element set to a value of "enable";

c) if user want to store all the authorized MCData group communications, and if requested to store the communications, shall include <store-all-group-comms-in-msgstore> element set to a value of "true". Otherwise, if user want to store the list of MCData group communications, and if requested to store the communications, shall include <store-specific-group-comms-in-msgstore> element set to a value of "enable";

d) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and

e) if the MCData client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias;

6) if the <store-specific-private-comms-in-msgstore> or the <store-specific-group-comms-in-msgstore> element is included in an application/vnd.3gpp.mcdata-info+xml MIME body, shall include an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body as specified in clause D.7 with the <msgstore-ctrl-command-list> element containing:

a) if the <store-specific-private-comms-in-msgstore> element set to a value of "enable", may include zero or more <private> elements of <enable> element containing a MCData ID of the MCData user; and

b) if the <store-specific-group-comms-in-msgstore> element set to a value of "enable", may include zero or more <group> elements of <enable> element containing a MCData Group ID; and

7) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].

21.3.2.3 Disable communications storage into message store procedures.

Upon receiving a request from the MCData user to send a request to control (i.e., disable) the storage of MCData communications request, if the <allow-store-comms-in-msgstore> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", the MCData client shall inform the MCData user and shall exit this procedure.

Upon receiving a request from the MCData user to send a request to disable the storage of MCData communications for private and/or group, the MCData client shall generate a SIP MESSAGE request in accordance with 3GPP TS 24.229 [5] and IETF RFC 3428 [6] with the clarifications given below.

The MCData client:

1) shall include a Request-URI set to the public service identity identifying the originating participating MCData function serving the MCData user;

2) shall include the ICSI value "urn:urn-7:3gpp-service.ims.icsi.mcdata" (coded as specified in 3GPP TS 24.229 [5]), in a P-Preferred-Service header field according to IETF RFC 6050 [7];

4) may include a P-Preferred-Identity header field in the SIP MESSAGE request containing a public user identity as specified in 3GPP TS 24.229 [5];

5) shall include an application/vnd.3gpp.mcdata-info+xml MIME body as specified in clause D.1 with the <mcdatainfo> element containing the <mcdata-Params> element with:

a) the <request-type> element set to a value of "store-comms-in-msgstore-ctrl-req";

b) if user do not want to store all the authorized MCData private communications, and if requested not to store the communications, shall include <store-all-private-comms-in-msgstore> element set to a value of "false". Otherwise, if user do not want to store the list of MCData private communications, and if requested not to store the communications, shall include <store-specific-private-comms-in-msgstore> element set to a value of "disable";

c) if user do not want to store all the authorized MCData group communications, and if requested not to store the communications, shall include <store-all-group-comms-in-msgstore> element set to a value of "false". Otherwise, if user do not want to store the list of MCData group communications, and if requested not to store the communications, shall include <store-specific-group-comms-in-msgstore> element set to a value of "disable";

d) the <mcdata-client-id> element set to the MCData client ID of the originating MCData client; and

e) if the MCData client needs to include an active functional alias in the SIP MESSAGE request, the <anyExt> element of the <functional-alias-URI> element set to the URI of the used functional alias;

a) if the <store-specific-private-comms-in-msgstore> element set to a value of "disable", may include zero or more <private> elements of <disable> element containing a MCData ID of the MCData user; and

b) if the <store-specific-group-comms-in-msgstore> element set to a value of "disable", may include zero or more <group> elements of <disable> element containing a MCData Group ID; and

7) shall send the SIP MESSAGE request according to rules and procedures of 3GPP TS 24.229 [5].

21.3.3 Participating MCData function procedures

21.3.3.1 General

The participating MCData function has procedures to:

– receive a MCData communications storage control request from the MCData Client.

21.3.3.2 Control communications storage into message store procedures.

Upon receipt of a "SIP MESSAGE request for controlling the storage of the MCData communications into MCData message store", the participating MCData function:

1) if unable to process the request due to a lack of resources or a risk of congestion exists, may reject the SIP MESSAGE request with a SIP 500 (Server Internal Error) response. The participating MCData function may include a Retry-After header field to the SIP 500 (Server Internal Error) response as specified in IETF RFC 3261 [4] and skip the rest of the steps;

2) shall determine the MCData ID of the calling user from the public user identity in the P-Asserted-Identity header field of the SIP MESSAGE request;

NOTE: The MCData ID of the calling user is bound to the public user identity at the time of service authorisation.

3) if the participating MCData function cannot find a binding between the public user identity and an MCData ID or if the validity period of an existing binding has expired, then the participating MCData function shall reject the SIP MESSAGE request with a SIP 404 (Not Found) response with the warning text set to "141 user unknown to the participating function" in a Warning header field and shall not continue with any of the remaining steps;

4) if the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request containing <request-type> element set to a value of "store-comms-in-msgstore-ctrl-req" and:

a) the <allow-store-comms-in-msgstore> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "234 user authorized to enable or disable the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause;

b) if the <store-all-private-comms-in-msgstore> element is present in the incoming request and the <allow-store-private-comms-in-msgstore> element of the <ruleset> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "234 user authorized to enable or disable the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause;

c) if the <store-all-group-comms-in-msgstore> element is present in the incoming request and the <allow-store-group-comm-in-msgstore> element of the each <MCDataGroupInfo> element is not present in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "234 user authorized to enable or disable the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause;

d) the SIP MESSAGE request does not contain an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body, the <store-all-private-comms-in-msgstore> element, and the <store-all-group-comms-in-msgstore> elements, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "235 unable to determine target user or group for enabling or disabling the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause;

e) if the <store-all-group-comms-in-msgstore> element is not present and an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body with zero or more <group> elements of <enable> or <disable> element are included, then each specified MCPTT group ID matches with the corresponding entry in the each <MCDataGroupInfo> do not contain the <allow-store-group-comm-in-msgstore> element in the MCData user profile document (see the MCData user profile document in 3GPP TS 24.484 [12]) or is set to a value of "false", shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "234 user authorized to enable or disable the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause; and

f) if the <store-specific-private-comms-in-msgstore> or <store-specific-group-comms-in-msgstore> is present and the request does not contain an application/resource-lists+xml MIME body, shall reject the SIP MESSAGE request with a SIP 403 (Forbidden) response including warning text set to "235 unable to determine target user or group for enabling or disabling the storage of MCData communications into the MCData message store" in a Warning header field, and shall not continue with the rest of the steps in this clause;

5) if the application/vnd.3gpp.mcdata-info+xml MIME body of the SIP MESSAGE request contains:

a) if the <store-all-private-comms-in-msgstore> element set to a value of "true", shall update or store the record for the MCData client and enable the storage of all the MCData private communications for which user is authorized to store the communication into the MCData message store;

b) if the <store-all-private-comms-in-msgstore> element set to a value of "false", shall update or store the record for the MCData client and disable the storage of all the MCData private communications for which user is authorized to store the communication into the MCData message store;

c) if the <store-specific-private-comms-in-msgstore> element set to a value of "enable", the <store-all-private-comms-in-msgstore> element is not present and an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body with one or more <private> elements of <enable> element are included, shall update or store the record for the MCData client and enable the storage of MCData private communications of the requesting user with specified list of users for which user is authorized to store the communication into the MCData message store;

d) if the <store-specific-private-comms-in-msgstore> element set to a value of "disable", the <store-all-private-comms-in-msgstore> element is not present and an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body with one or more <private> elements of <disable> element are included, shall update or store the record for the MCData client and disable the storage of MCData private communications of the requesting user with the specified list of users for which user is authorized to store the communication into the MCData message store;

e) if the <store-all-group-comms-in-msgstore> element set to a value of "true", shall update or store the record for the MCData client and enable the storage of all the MCData group communications for which user is authorized to store the communication into the MCData message store;

f) if the <store-all-group-comms-in-msgstore> element set to a value of "false", shall update or store the record for the MCData client and disable the storage of all the MCData group communications for which user is authorized to store the communication into the MCData message store;

g) if the <store-specific-group-comms-in-msgstore> element set to a value of "enable", the <store-all-group-comms-in-msgstore> element is not present and an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body with one or more <group> elements of <enable> element are included, shall update or store the record for the MCData client and enable the storage for the specified MCData group communications for which user is authorized to store the communication into the MCData message store; and

h) if the <store-specific-group-comms-in-msgstore> element set to a value of "disable", the <store-all-group-comms-in-msgstore> element is not present and an application/vnd.3gpp.mcdata-msgstore-ctrl-request+xml MIME body with one or more <group> elements of <disable> element are included, shall update or store the record for the MCData client and disable the storage for the specified MCData group communications for which user is authorized to store the communication into the MCData message store;

6) shall generate a SIP 200 (OK) response as specified in 3GPP TS 24.229 [5] with the following clarifications:

a) shall include the public user identity in the P-Asserted-Identity header; and

7) shall send the SIP 200 (OK) response to the MCData client according to 3GPP TS 24.229 [5].