Meeting minutes
Review continued
Ulf: we walked through the Core document on previous call, received a number of responses and some in the github issue
… I reviewed the minutes and the issue and updated our document
… all are very good comments. the only one I have a different view on is about capitalization
… Peter wasn't a fan of the style
Peter: it is used everywhere although perhaps not grammatically correct
Ulf: it adds some value
… it helps it stand out, having Client in the middle of a sentence it looks strange but helps
Peter: if everyone agrees it helps, I withdraw my reaction
Gunnar: I side with Ulf
… not opposed to highlighting in some other manner. we should strive for being consistent
… Peter found idea of a different font worse
Ted: I looked at some other specs, Manu Sporny is a long term editor and typically did init capitalization for the first time it is brought up, typically in a header and then lower case and linked throughout
… so it is a good balance. they might be using some Respec feature to do that automatically using id and I'll look into that more and work with Ulf on the changes
Ulf: that is a good compromise
Peter and Gunnar agree
Ulf: all feedback so far on Core is in Google doc and we can go into Transport now
… abstract needs more and Ted agreed to work on that along with intro
… Transport Common Definition makes clear that regardless of protocol (WebSocket, HTTP or other) that should be used such as status codes
… status codes leveraged from VISS v1 and we should look if this is how we want them presented
… protocol supports error code, reason and message
… these should be reviewed and may have some scenarios that are not addressed
… payload is a common part, in JSON across all protocols
… authorization is required across protocols
… we have a concept of session lifetime management, more for WebSocket not so for HTTP
Ted: HTTP is a stateless protocol and people have added via eg nonce in querystring or cookies
… both have their downsides. first question is are there any benefits of having a session?
Ulf: please create an issue so we can explore that further
Ted: will do
Ulf: we have Read, Update, Subscribe and their capabilities consistent with both protocols
… examples are given for requests and responses
… we have variants in the chapters, such as token based authentication
… search/query syntax explained, example request/response provided
… another type of read could be the history read
… we have variants based on single or multiple path selection
Gunnar: it might be a good idea to just include the headers needed as some, eg leave out the user-agent string
Ted: I can help review and pare down headers to include
Ulf: update is simpler case
… in WebSocket we have more for instance on session management
… I copied a number of parts from VISS v1 and should be reviewed in detail including example given
… we have the same basic structure on methods. the layout/format is a bit different with the tables as they came over from v1
… I like the look
Ted: maybe we should be consistent and do similar for HTTP?
Ulf: maybe but we have some substantial differences between them
… I am following a consistent pattern for methods across WebSocket
… we have asynchronous methods when conditions met...
… we have curve logic support in subscription
Ted: curve logic was headed to GENIVI, was that finalized and can we reference it?
Glenn: we don't have it ready to post yet but it is imminent on Geotab github
Gunnar: it will be published as an open source project, hosted by Geotab. GENIVI will write a tech brief
Ted we'll need to explain concept and point to Geotab's algorithm as an example
Ulf: we have attribute definitions and for JSON schema as well
… perhaps this belongs more in Core document as it is not protocol specific
Ted: we should have clear understanding of what belongs where and you and I can review with that in mind
Gunnar: in some cases concepts may be worth duplicating
Ted encourages further reading offline, convention is to use catch all unless feature/substantive
https://
Ulf: MagnusG, Peter and I are playing around with MQTT in our implementation
Ted: if you have it implemented, we may want to add to transport spec
Ulf: that is a possibility
… still early on
Peter: we are using it for various purposes at Volvo
… there are as you said performance gains
… we also looked at WAMP some
… we already have concept of brokers
Gunnar: WAMP's features included a number of MQTT features while being more Web like
… plus RPC calls
… attempts to do RPC on MQTT seems kind of cludgy