Confirmed users
632
edits
(→Format of Data: Add info on the contentType) |
No edit summary |
||
| (2 intermediate revisions by one other user not shown) | |||
| Line 20: | Line 20: | ||
== Format of Data == | == Format of Data == | ||
The format of the data will vary for different channels, according to the requirements for data across that channel. | |||
=== "Text" Data Channel === | |||
Data sent across the "text" data channel should be encoded in standard JSON format. | |||
=== Text Messages === | Individual data types shall have their own defined structures, with contentType being the type of message. | ||
Notes: | |||
* Implementations should ignore messages with an unknown contentType, this is for forward compatibility. | |||
** ''It may be necessary in furture to have a capability detection system.'' | |||
* Implementations should not fail if additional fields are sent within an known message content type. | |||
==== Text Messages ==== | |||
{ | { | ||
| Line 38: | Line 46: | ||
* sentTimestamp: An ISO encoded date | * sentTimestamp: An ISO encoded date | ||
Notes for implementations: | |||
* Implementations shall handle security concerns around not processing embedded HTML. | |||
* Implementations should handle their own received timestamp, so that messages are displayed in the correct order e.g. in case of clock skew across the two machines. | |||
* Implementations should handle linkifying URLs when the message is displayed. These shall not affect the transmitted content. | |||