Vehicle Signal Server Spec Actions

[acrofts84]

Here is a list of the current actions on the Vehicle Signal Server Spec, from our review in Lisbon. These have been copied from my notes, so feel free to ask for any clarification.

• ACTION – Table of figures to join table of contents. It looks a bit out of place where it currently is
• ACTION – TTL units – milliseconds
• ACTION – Message structure. Get rid of void and DOMString to make it JavaScript, like onmessage. Vehicle.onmessage, not WebSocket.onmessage
• ACTION – Example 3, make it obvious that it is one of the three, not all three
• ACTION – be explicit that server side filtering is for nodes only, not for branches
• ACTION – move getVSS before the other actions. Authorize, getVSS, then get, set, subscribe, unsubscribe
• ACTION – Add a Subscription notification error message for when the server is overloaded. It returns the following information (timestamp, subId, reqId, error, filter)
• ACTION – the wildcard example needs to be improved. Body.doors.*.something. Result value doesn’t include left, right, etc.
• ACTION – Add unsubscribeAll action instead of using subscriptionId: 0 to avoid use of magic number
• ACTION – getVSS method should be hyperlink (just under Fig 2)
• ACTION - Shorten the abstract to give high level overview, integrate any extra info into the introduction
• ACTION – OCF JSON Schema – use this structure to make the objects consistent. Wonsuk to share
• ACTION – DOMStrings vs strings ?
• ACTION – VSS is minor version, VSSS is major version wvss1.0
• ACTION – unsubscribe all when there are no subscriptions
• ACTION – other data formats may be added in the future. Add a github issue for discussion. CSV, BSON, YAML etc. JSON will be current format
• ACTION – If auth fails during subscription, we need to send a subscription notification error response. Does the subscription continue, or do we need to resubscribe? It should just continue – as discussed.
• ACTION – comments around JSON in examples
• ACTION - wwwivi add note to name server on the LAN has to assign an address
• ACTION – Set engine.rpm cannot be set because its read-only
• ACTION – after 10 (or N) number of requests the authentication will be denied to avoid dictionary attacks. Will return a denied after this. (User / device token error mechanism)
• ACTION – more generic hostname, not just for IVI. Discuss with WoT. Do we want this to be generic? With a different sub-protocol.
• ACTION – add get VSS to example with AUTH section
• ACTION – add getVSS request and receive notes.
• ACTION – potentially add editor’s notes for open issues, such as branches for filters. For where we want input from outside
• ACTION – Strip out some content in the Initialisation section
• ACTION – explicitly state that the tree unsubscribes from an entire subscription, you cannot just do just a subset
• ACTION – add a state diagram for all of the state changes depending on messages sent – get Visio going! Particularly showing auth, and error messages when there are too many requests.
• Provide comment about application level tokens, and protection against replays/spoofing of tokens

Reconsidering the following:

• ACTION – private path error should be a forbidden (private_path instead of not found)
  • Having looked at this further, I think that it should remain as not_found, as knowing that a signal existed could be sensitive data in itself. It is better to err on the side of caution here.
• ACTION – add timestamps to request objects so that only one response is received, the latest. This can be abstracted by the client spec.
  • The adds a lot of overhead for the server each time a request is made. It would have to check that another thread is not dealing with the same request each time it tries to satisfy a request. This means it would increase demand on the server rather than reduce it. The advantage is that the client only receives the data once, but really it should ask for it only once.
  • Agreed on call 20/6/17. 429 error covers this case

[rstreif]

Per Working Group Meeting: @drkevg, @acrofts84, and the editors and chairs review the list and clear the remaining items.

[rstreif]

AR: @drkevg and @acrofts84, please review and check off the remaining items from the list.

[peterMelco]

@drkevg On state diagram for VISS.

• I would add what is server and what is client , just for clearity.
• What is access control state ? It sort of implies that server is a state machine based on one particular client auth data - that is not the case in our ref implementation. I am missing something here probably...

[drkevg]

Added new State Diagram section and diagram to end of Architecture section. Added statement to specify that client and the server are each individually responsible for implementing security best practice to prevent replays or spoofing of tokens by malicious actors or agents. All items now implemented, hence closing issue.