Skip to content

Update WRP Spec for deviceID #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

Update WRP Spec for deviceID #53

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d36ce77
Update spec
Aug 14, 2020
5df70e1
add back dest field
Aug 14, 2020
7700f5b
Apply suggestions from code review
schmidtw Mar 22, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 20 additions & 11 deletions content/docs/wrp/simple-messages.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,22 +12,29 @@ To make the document easier to read, the msgpack is written out in a bit more
human readable format.

One design goal for the message definition is to make sure it can be translated
to and from JSON and HTTP headers as well as it's native msgpack format.
to and from JSON and HTTP headers as well as its native msgpack format.

Messages currently flow in two directions:
- Inbound: API requests to devices.
- Outbound: responses from devices for corresponding inbound requests as well as
events related to device activity (rebooting, updating, offline).

## Simple Request-Response Definition

This is one of the primary message definitions used. This provides a point to
point (request, response) semantic. An example of where this message is used is
between Webpa's `Tr1d1um` machine and the `Parodus2ccsp` client that interprets
the request, gathers data and responds back. Both requests and responses use
the same message type.
point (request, response) semantic between an API user that makes requests and
a device client which responds to them. An example of where this message is used is
between Webpa's `Tr1d1um` which sends requests on behalf of API users and the
`Parodus2ccsp` client that interprets such requests, gathers data and responds back.
Both requests and responses use the same message type.

#### Schema
~~~~~
{
Integer msg_type = 3
String source
String dest
String device_id
String content_type
String accept
String transaction_uuid
Expand All @@ -47,9 +54,10 @@ the same message type.
Name | Description
-----|--------------
msg_type | The message type for the request-response. (**SHALL** be 3.)
source | The device_id name of the device originating the request or response.
dest | The device_id name of the target device of the request or response.
content_type | (optional) The media type of the payload.
source | The locator information of the creator of the request or response (i.e. dns:tr1d1um.example.net for inbound messages).
dest | The locator information of the target device of the request or response (i.e. mac:112233445566/config for inbound messages).
device_id | The canonical device ID (i.e. mac:112233445566) that this message is related to. It differs from source or dest in that no further parsing is required to extract the ID from various fields.
content_type | (optional) The media type of the payload. If not specified on inbound messages, `application/octet-stream` is used as default.
Copy link
Contributor

@kristinapathak kristinapathak Aug 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were only adding this for events? Is this also being added to request-responses?

Copy link
Contributor

@kristinapathak kristinapathak Aug 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, found the pull request (xmidt-org/webpa-common#508). But isn't it filled in for outbound messages, not inbound?

accept | (optional) The media type accepted in the response.
transaction_uuid | The transaction key for the request and response. The requester may have several outstanding transactions, but must ensure that each transaction is unique per destination. This **SHOULD** be a UUID, but the web router **SHALL** NOT validate this data. The web router **SHALL** treat this data as opaque.
status | (optional) The response status to the originating service. Not included in the during the request.
Expand Down Expand Up @@ -96,9 +104,10 @@ great at sending metrics, publishing a report, sending an SOS.
Name | Description
-----|--------------
msg_type | The message type for the simple event. (**SHALL** be 4.)
source | The device_id name of the device originating the request or response.
dest | The device_id name of the target device of the request or response.
content_type | (optional) The media type of the payload.
source | The locator information of the creator of the event (i.e. mac:112233445566/config)
dest | An event locator of the form: `event:{event identifier}/{ignored}`. The main use case is for listeners to register only for events they care about.
device_id | The canonical device ID (i.e. mac:112233445566) that this message is about. The source may not always be or include the device ID (for example, if talaria creates an event about a device connecting to it).
content_type | (optional) The media type of the payload. If not specified on inbound messages, `application/octet-stream` is used as default.
partner_ids | (optional) The list of partner ids the message is meant to target. If the item is missing and the device has a `partner id` or the device does not find a match, the request shall be disregarded.
headers | (optional) The headers associated with the payload.
metadata | (optional) The map of name/value pairs used by consumers of WRP messages for filtering & other purposes.
Expand Down