The MCData message store allows an MCData user to deposit his MCData communication information (i.e. messages or files) securely and permanently for later retrieval. During an active MCData communication, a message or a file with its associated metadata is deposited as an object in the MCData message store with an object identifier; this object identifier enabling a direct access to that object. The objects in the MCData message store are managed from both the MCData server and the message store client.
Each MCData user is allocated a dedicated and secured storage area (i.e. with a user account) in the MCData message store. All MCData communications of a MCData user can be stored in his dedicated storage area. The access to this secured storage area is possible only after successful authentication and authorization procedures. A message store client can create a local copy of the stored objects into the device by synchronizing with the MCData message store for the MCData user using the device.
MCData message store supports a tree like architecture to securely store MCData communications for the MCData users. Figure 7.13.1 below illustrates the high-level structure of a MCData message store:
As illustrated in Figure 7.13.1 all MCData user storage areas are accessed only through the common root. The authorized MCData user shall only have the access to the MCData user's storage area after the successful authentication and authorization procedures. A MCData user shall not be able to access objects stored for other MCData users.
The MCData user shall manage his stored objects using message store client through the MCData-7 reference point. The MCData server shall use the MCData-8 reference point to deposit MCData communication information, during an active MCData communication, into the designated MCData user's storage area in the MCData message store.
One way to manage user stored objects is using folder hierarchy structure like the popular email system today. Annex D provides a simple example of how it will look like in deployment. When the user account is created in the MCData message store, a default folder (such as Inbox) is also created to capture all the objects during an active communication. To group relevant stored objects together and provide easier navigation interactively, a MCData user can create folders in his user account. Each folder is identified by its unique folder identifier that is composed with the location of the folder and the name of the folder. A folder may have child folders to further group the stored objects in more meaningful ways. For example, the folder identifier of the default Inbox folder is /MCDatamessagestore/MCDatauser1/Inbox. The folder identifier /MCDatamessagestore/MCDatauser1/Squad1/20190225 points to a folder named 20190225 which is a child folder of Squad1 folder in the MCData user1 user account.
The MCData message store shall authenticate the credential of MCData server or the authorized MCData user before authorizing access to the MCData user's storage area. The success of authentication and authorization shall allow access to that MCData user's storage area only.
Table 7.13.3.1.1-1 describes the information flow for the MCData retrieve a stored object request sent from the message store client to the MCData message store.
Table 7.13.3.1.2-1 describes the information flow for the MCData retrieve a stored object response sent from the MCData message store to the message store client.
The stored object identified by the object identifier in the request. This information element shall be returned as empty when there is no stored object can be identified by the object identifier in the request
Table 7.13.3.1.3-1 describes the information flow for the MCData search stored objects request sent from the message store client to the MCData message store.
Table 7.13.3.1.4-1 describes the information flow for the MCData search stored objects response sent from the MCData message store to the message store client.
The stored object(s) that meets the search criteria. This information element shall be returned as empty when there is no stored object can be identified by the search criteria in the request
Table 7.13.3.1.5-1 describes the information flow for the MCData update a stored object request sent from the message store client to the MCData message store.
Table 7.13.3.1.6-1 describes the information flow for the MCData update a stored object response sent from the MCData message store to the message store client.
Table 7.13.3.1.7-1 describes the information flow for the MCData delete a stored object request sent from the message store client to the MCData message store.
Table 7.13.3.1.8-1 describes the information flow for the MCData delete a stored object response sent from the MCData message store to the message store client.
Table 7.13.3.1.9-1 describes the information flow for the MCData synchronization request sent from the message store client to the MCData message store.
Table 7.13.3.1.10-1 describes the information flow for the MCData synchronization response sent from the MCData message store to the message store client.
The stored objects that need to be synchronized with the device local message store. Empty information element means no stored objects need to be synchronized
Table 7.13.3.1.11-1 describes the information flow for the MCData create a user account request sent from the MCData server to the MCData message store.
Table 7.13.3.1.12-1 describes the information flow for the MCData create a user account response sent from the MCData message store to the MCData server.
The object identifier that will be used to retrieve this object in the MCData message store directly. If this information element is empty it means the object is not stored
Table 7.13.3.1.15-1 describes the information flow for the MCData copy a stored object request sent from the message store client to the MCData message store.
Table 7.13.3.1.16-1 describes the information flow for the MCData copy a stored object response sent from the MCData message store to the message store client.
Table 7.13.3.1.17-1 describes the information flow for the MCData move a stored object request sent from the message store client to the MCData message store.
Table 7.13.3.1.18-1 describes the information flow for the MCData move a stored object response sent from the MCData message store to the message store client.
Table 7.13.3.1.19-1 describes the information flow for the MCData create folder request sent from the message store client to the MCData message store.
Table 7.13.3.1.20-1 describes the information flow for the MCData create folder response sent from the MCData message store to the message store client.
Table 7.13.3.1.21-1 describes the information flow for the MCData delete folder request sent from the message store client to the MCData message store.
Table 7.13.3.1.22-1 describes the information flow for the MCData delete folder response sent from the MCData message store to the message store client.
If no folder identifier information element is provided in the request, the MCData message store returns folders from the root of the user account. If folder identifier information element is provided in the request, the MCData message store returns the child folders from that folder identifier provided.
Table 7.13.3.1.29-1 describes the information flow for the MCData upload objects request sent from the message store client to the MCData message store.
Table 7.13.3.1.30-1 describes the information flow for the MCData upload objects response sent from the MCData message store to the message store client.
Table 7.13.3.1.31-1 describes the information flow for the MCData synchronization notification sent from the MCData message store to the message store client.
Table 7.13.3.1.32-1 describes the information flow for the create notification channel request sent from the message notification client to the MCData notification server.
Table 7.13.3.1.33-1 describes the information flow for the create notification channel response sent from the MCData notification server to the message notification client.
The identity of the MCData client initiating the request
Validity duration
M
How long the notification channel will last (i.e. channel lifetime) as granted by the MCData notification server
Notification URL
O
The URL to receive the notification message if a Pull method is requested . For some PUSH method implementation (such as WebSockets) this URL is used to start the PUSH notification service from the MCData notification server
Callback URL
M
The URL used by the Message notification client to subscribe to MCData message store notifications
Table 7.13.3.1.34-1 describes the information flow for the open notification channel sent from the message notification client to the MCData notification server.
Table 7.13.3.1.35-1 describes the information flow for the subscribe for notification request sent from the message store client to the MCData message store.
The identity of the MCData client initiating the request
Callback URL
M
The URL where to send the notification message
Validity duration
M
How long the subscription to notification will last (i.e. subscription lifetime); this value shall be the returned value in the create notification channel response
Table 7.13.3.1.36-1 describes the information flow for the subscribe for notification response sent from the MCData message store to the message store client.
Table 7.13.3.1.37-1 describes the information flow for the MCData search folder request sent from the message store client to the MCData message store.
Any part of the folder information (such as metadata) can be used as the search criteria. Linking multiple parts of the folder information as the search criteria is possible
Table 7.13.3.1.38-1 describes the information flow for the MCData search folder response sent from the MCData message store to the message store client.
Table 7.13.3.1.39-1 describes the information flow for the MCData retrieve folder content request sent from the message store client to the MCData message store.
Table 7.13.3.1.40-1 describes the information flow for the MCData retrieve folder content response sent from the MCData message store to the message store client.
The content of the requested folder; such as objects and subfolders. This information element shall be returned as empty if the requested folder is not found.
Table 7.13.3.1.41-1 describes the information flow for the MCData retrieve file to store locally request sent from the message store client to the MCData message store and from the MCData server to the MCData message store.
Table 7.13.3.1.42-1 describes the information flow for the MCData retrieve file to store locally response sent from the MCData message store to the message store client and the MCData server.
Table 7.13.3.1.43 describes the information flow for the update notification channel request sent from the message notification client to the MCData notification server.
Table 7.13.3.1.44 describes the information flow for the update notification channel response sent from the MCData notification server to the message notification client.
Table 7.13.3.1.45 describes the information flow for the update notification subscription request sent from the message store client to the MCData message store.
The identity of the MCData client initiating the request
Validity duration
M
How long the notification channel will last (i.e. notification subscription lifetime). This value should be the returned value in the update notification channel response
Table 7.13.3.1.46 describes the information flow for the update notification subscription response sent from the MCData message store to the message store client.
Table 7.13.3.1.47 describes the information flow for the delete notification channel request sent from the message notification client to the MCData notification server.
Table 7.13.3.1.48 describes the information flow for the delete notification channel response sent from the MCData notification server to the message notification client.
Table 7.13.3.1.49 describes the information flow for the delete notification subscription request sent from the message store client to the MCData message store.
Table 7.13.3.1.50 describes the information flow for the delete notification subscription response sent from the MCData message store to the message store client.
Table 7.13.3.1.51-1 describes the information flow for the notification message sent from the MCData message store to the MCData notification server and from the MCData notification server to the MCData notification client.
The specific information carried in the notification message to inform the MCData client of changes to the MCData message store. (see NOTE)
NOTE:
MCData client uses the event information for actions such as updating its local message store or uses the event as a trigger for inquiring the Message store for desired changes.
A stored object can be retrieved from the MCData message store with the known object identifier that is generated by the MCData message store when the object was deposited.
The procedure in Figure 7.13.3.2.2-1 describes the case when a message store client retrieves a stored object from the MCData message store using the known object identifier.
Pre-conditions:
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client knows the object identifier of the stored object.
The message store client would like to retrieve a stored object from the MCData message store and initiates a MCData retrieve a stored object request toward the MCData message store. The unique object identifier of the stored object is included in the request.
The message store client can search stored objects in the MCData message store with certain criteria. This procedure allows the message store client to look for stored object(s) without knowing the object identifier(s) of the object. This procedure also allows the message store client to retrieve stored objects that are related to each other; such as all messages and files exchanged in a conversation.
The procedure in Figure 7.13.3.3.2-1 describes the case when a message store client searches and retrieves relevant stored objects from the MCData message store.
Pre-conditions:
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client would like to retrieve stored objects that meet certain criteria (such as with the same Conversation identifier) and initiates a MCData search objects request toward the MCData message store. The search criteria are included in the request.
The procedure in Figure 7.13.3.4.2-1 describes the case when a message store client updates metadata of a stored object in the MCData message store.
Pre-conditions:
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client knows the object identifier of the stored object.
The message store client would like to update the metadata of a stored object (such as "flagged") and initiates a MCData update a stored object request toward the MCData message store. The stored object's object identifier and the updated meta data are included in the request.
The MCData message store locates the stored object with the object identifier and updates its metadata as carried in the MCData update a stored object request and communicates the result in the MCData update a stored object response.
The procedure in Figure 7.13.3.5.2-1 describes the case when a stored object in the MCData message store is deleted by the message store client of an authorized MCData user.
Pre-conditions:
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client knows the object identifierof the stored object.
The MCData user is authorized to delete the stored object.
The message store client would like to delete a stored object in the MCData message store and initiates a MCData delete a stored object request toward the MCData message store. The stored object's object identifier is included in the request.
The MCData message store locates the stored object with the object identifier and permanently removes it from the MCData message store. It then communicates the result in the MCData delete a stored object response.
The message store client can synchronize its local message store with the MCData message store. Different level of synchronization shall be supported with a filter in the request.
The procedure in Figure 7.13.3.6.2-1 describes the case when a message store client synchronizes its local message store with the MCData message store for a MCData user.
Pre-conditions:
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client would like to synchronize its local message store with the MCData message store. It initiates the MCData synchronization request toward the MCData message store. The synchronization type and optional filter criteria are included in the request to indicate the type of synchronization (such as full synchronization, partial synchronization etc.) is requested.
The MCData message store returns all the stored objects, based on the synchronization filter criteria, to the message store client in the MCData synchronization response.
When the MCData server is ready to deposit an object into the MCData user's storage area in the MCData message store the MCData user's storage area (i.e. user account) needs to be created already. If the user account is not created, the MCData server shall create the user account (i.e. allocate the MCData user's storage area in the MCData message store) first and then deposit the subsequent MCData communications.
The procedure in Figure 7.13.3.7.2-1 describes how the MCData server creates a user account (allocate MCData user storage area) in the MCData message store.
Pre-conditions:
A successful authentication and authorization has been performed between the MCData server and the MCData message store.
No storage area in the MCData message store has been allocated for the MCData user; i.e. no user account has been created.
The MCData server is authorized to create user accounts on the MCData message store.
The MCData server would like to create a MCData user account in the MCData message store to store the MCData communication for that MCData user and initiates a MCData create a user account request toward the MCData message store. The MCData ID of the MCData user is included in the request.
The MCData message store creates a user account (i.e. allocate dedicated and secured storage area) for the MCData user as specified in the request and communicates the result back to the MCData server in the MCData create a user account response.
MCData server needs to store the communication information (i.e. an object) for a MCData user during an active MCData communication. If there is a file URL in the object for file distribution in the communication, the MCData server may instruct the MCData message store to retrieve a copy of the file to store locally in the MCData user's account.
The procedure in Figure 7.13.3.8.2-1 describes how the MCData server deposit an object into the MCData message store during an active MCData communication.
Pre-conditions:
A successful authentication and authorization has been performed between the MCData server and the MCData message store.
The MCData user has been allocated a secured storage area in the MCData message store.
The configuration to store the MCData communication in MCData message store is enabled for the MCData user.
MCData user has requested to store his MCData communication and also store the distributed file content into his MCData message store account if the MCData communication is for file distribution through URL.
The MCData server would like to deposit a MCData communication information (i.e. object) to the MCData user's storage area in the MCData message store and initiates a MCData deposit an object request toward the MCData message store. The object is constructed by the MCData server and is included in the request. If the object is a message that carries a URL for file distribution, the MCData server may instruct the MCData message store to retrieve a copy of the file and store locally in the MCData user's account by setting the retrieve file indication information element to true.
The MCData message store deposits the object into the MCData user's storage area. If the retrieve file indication is set in the MCData deposit an object request the MCData message store retrieves the file URL from the stored object and fetches the file content from the MCData content server.
The MCData message store stores the file content into the MCData user's storage area and update the object with the URL referencing the file content stored in the MCData user's storage area.
The MCData message store communicates the result back to the MCData server in the MCData deposit an object response. The object identifier of the stored object is returned.
A stored object in the MCData message store can be copied to another location (i.e. folder) in the same MCData user account where there is no such object stored. After the successful object copy operation, the object will exist in both the original and destination locations. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
The procedure in Figure 7.13.3.9.2-1 describes the case when a stored object is copied to a different location in the same MCData user account.
Pre-conditions:
The MCData user has an account in the MCData message store.
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client knows the object identifier of the stored object and the destination folder identifier.
The message store client would like to copy a stored object in the MCData message store to a destination folder and initiates a MCData copy a stored object request toward the MCData message store. The uniqe identifier of the stored object and the destination folder are included in the request.
A stored object in the MCData message store can be moved to a different location (i.e. folder) in the same MCData user account. After the successful object move operation the object will only exist in the new location. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
The procedure in Figure 7.13.3.10.2-1 describes the case when a stored object is moved to a different location in the same MCData user account.
Pre-conditions:
The MCData user has an account in the MCData message store.
A successful authentication and authorization have been performed between the message store client and the MCData message store.
The message store client knows the object identifier of the stored object and the destination folder identifier.
The message store client would like to move a stored object in the MCData message store to a destination folder and initiates a MCData move a stored object request toward the MCData message store. The uniqe object identifier of the stored object and the destination folder are included in the request.
A user can create a new folder in his user account n the MCData message store. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
The MCData user would like to create a new folder in his user account in the MCData message store, the message store client initiates a MCData create folder request toward the MCData message store. The parent folder identifier and the folder name are included in the request to indicate where the new folder will be created.
The MCData message store creates the user folder in the location specified in the request. If the folder name is provided in the request, the MCData message store creates the folder with the provided folder name. If the provided folder name has a conflict or no folder name is provided in the request, the MCData message store assigns a name for the new user folder.
A user can delete an existing folder in his user account in the MCData message store. All the child folders and objects stored in that folder will be deleted. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
The MCData user would like to delete an existing folder in his user account in the MCData message store, the message store client initiates a MCData delete folder request toward the MCData message store. The folder identifier of the folder to be deleted is included in the request.
The MCData message store identifies the target folder and deletes it from the user account. All the child folders and objects stored in this folder are also deleted.
A user can copy an existing folder in his user account to a different location. All the child folders and objects stored in that folder will be copied to the new folder. The name of the new folder will be the same as the folder it copies from or the name provided in the request. This operation is only meaningful when the user account in the MCData message store is structured in the folder hierarchy.
The MCData user would like to copy an existing folder in his user account in the MCData message store, the message store client initiates a MCData copy folder request toward the MCData message store. The folder identifiers of the source and destination folders and the new folder name are included in the request.
The MCData message store copy the source folder to the destination with the new folder name. If no new folder name is provided in the request, the source folder name will be used. All the child folders and objects stored in this folder are also copied to the new folder.