Merge conflict fix

Signed-off-by: Ulf Bjorkengren <[email protected]>

VISS-explainer.md

@@ -1,25 +1,25 @@
 # VISS - Vehicle Information Service Specification Explainer
 
 Modern vehicles use hundreds of sensors which produce thousands of different data points, or signals, amounting to terabytes of data available per vehicle per day. The data points available on modern vehicles range from door lock state, fuel or charge level to tire pressure sensors and anti-lock brake control unit status. There is no question vehicles are transforming, becoming connected, electric and autonomous all of which relies extensively on signals data. 
-A common and standardized data model and interface would facilitate rapid innovation and development of various use cases involving this data.
+A common and standardized data model and interface facilitates rapid innovation and development of various use cases involving this data.
 
-At the center of this effort is a common data model for these vehicle signals, namely the Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) which has its own [explainer](https://www.covesa.global/sites/default/files/COVESA%20Vehicle%20Signal%20Specification_060122.pdf). To access this data in a standardized way an effort to develop an interface was initially started by W3C in collaboration with COVESA and in 2024 was transferred fully to [COVESA](https://covesa.global), the Vehicle Information Service Specification (VISS). The service can reside either in the vehicle, or in the cloud. Client applications can also reside in the vehicle, cloud or running on a nomad device such as a smartphone. 
+At the center of this effort is a common data model for these vehicle signals, namely the Vehicle Signal Specification ([VSS](https://covesa.github.io/vehicle_signal_specification/)) which is explained here [explainer](https://covesa.global/vehicle-signal-specification/). To access this data in a standardized way an effort to develop an interface was initially started by W3C in collaboration with COVESA and in 2024 was transferred fully to [COVESA](https://covesa.global), the Vehicle Information Service Specification (VISS). The service can reside either in the vehicle, or in the cloud. Client applications can also reside in the vehicle, cloud or running on a nomad device such as a smartphone. 
 
 Vehicle signals, the definition and access to them, has historically been OEM proprietary. This has made it difficult for suppliers, commercial fleets, 
 tech companies, insurance companies, regulators and other interested parties to integrate across vehicle brands. Furthermore, since VISS and VSS are open standards their use will reduce cost, promote innovation, interoperability and facilitate third party software development.
 
-VSS uses a tree structure with well defined open definitions, but it also has the ability to be extended to handle new and /or proprietary signals if 
+VSS uses a tree structure with well-defined open definitions, but it also has the ability to be extended to handle new and /or proprietary signals if 
 needed. The [transport](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Transport.html) and [access (API)](https://raw.githack.com/COVESA/vehicle-information-service-specification/main/spec/VISSv2_Core.html) together comprise the VISS version 2 specification, that includes HTTPS, MQTT, as well as Websockets which was the only 
 transport protocol supported in the [first version of VISS](https://www.w3.org/TR/vehicle-information-service/). The second and current version of VISS also includes a complete access control model, ability to support a consent model, and filtering techniques to better fit OEM requirements. 
 
-The intention is to use web technologies to facilitate development of applications with limited, trusted entities and not to make vehicles available for arbitrary connections over the web. Access to specific data points and use of the information is outside of the scope of this work. It is expected automotive manufacturers will govern which parties can run logic on or against vehicles, manage permissions, conduct security and legal/privacy audits. Regulators and courts, [Massachussets Right to Repair lawsuit as an example](https://www.natlawreview.com/article/automakers-lawsuit-opposing-updates-to-massachusetts-right-to-repair-law-lingers), will undoubtedly influence this as well. VISS was designed as a technical solution to be flexible in accomodating the future business ecosystem. The COVESA Security and Data Expert Groups along with the W3C Automotive Privacy Principles Community Group will likely produce formal best practices which will include security and privacy aspects.
+The intention is to use web technologies to facilitate development of applications with limited, trusted entities and not to make vehicles available for arbitrary connections over the web. Access to specific data points and use of the information is outside the scope of this work. It is expected automotive manufacturers will govern which parties can run logic on or against vehicles, manage permissions, conduct security and legal/privacy audits. Regulators and courts, [Massachussets Right to Repair lawsuit as an example](https://www.natlawreview.com/article/automakers-lawsuit-opposing-updates-to-massachusetts-right-to-repair-law-lingers) and the [EU data act](https://www.eu-data-act.com) will undoubtedly influence this as well. VISS was designed as a technical solution to be flexible in accomodating the future business ecosystem. The COVESA Security and Data Expert Groups formal best practices which will include security and privacy aspects.
 
 VISS version 1 deferred on access control to individual implementations and as mentioned only supported Websockets. Of the thousands of data points potentially available, a client application could subscribe to an allowed subset, and thus receive initial and updated values over time. The second version expanded on the filters available for Websocket and MQTT subscriptions and also allows for individual requests over these protocols and HTTPS of individual signals or if allowed a set of specified signals. For example, issuing a request to the node Vehicle.Drivetrain.Transmission would, if authorized, return all data available for a vehicle's transmission. 
 
 _Notes on implementation and use_
 
 VISS has known implementations by Volvo, BMW, JLR, Renesas, Bosch, Visteon, Geotab, AGL and Mitsubishi Electric to name a few. 
-The underlying data model VSS is seeing much wider adoption, eg within AWS Fleetwise, Blackberry Ivy as well as having accompanying ontology ([VSSo](https://www.w3.org/TR/vsso/)) and graph schema for machine learning and generating knowledge graphs, since its uses go far beyond a single API.
+The underlying data model VSS is seeing much wider adoption, e.g. within AWS Fleetwise, Blackberry Ivy as well as having accompanying ontology ([VSSo](https://www.w3.org/TR/vsso/)) and graph schema for machine learning and generating knowledge graphs, since its uses go far beyond a single API.
 
 A client application for example could reside on the vehicle itself on an on-board logic, telematics or head unit. From there it can authenticate itself against VISS and based on permissions granted for the specific application, can read or even write data to/from the vehicle. Applications may be user facing, providing information to operator or occupants or performing data sampling for analysis.
 

spec/VISSv3.0_Core.html

@@ -1843,16 +1843,16 @@ <h2>File Transfer</h2>
           }
           </code></pre>
           The FileDescriptor name member SHALL have a dot separated file extension that identifies the file format.<br>
-          The FileDescriptor hash member SHALL be a SHA-1 hash calculated on the content of the file.<br>
-          The FileDescriptor uid member SHALL be a base64 encoded random uint64 value.<br><br>
+          The FileDescriptor hash member SHALL be a SHA-1 hex string encoded hash calculated on the content of the file.<br>
+          The FileDescriptor uid member SHALL be a hex string encoded random uint32 value.<br><br>
           File transfer from client to server, or in the other direction, follows the model shown in the two sequence diagrams below.
           The server exposes two communication channels, a control channel and a data channel.
           The control channel is the channel where the primary VISSv3.0 payloads are communicated, 
           while the data channel is a channel over which the the file transfer data is communicated.
           The file transfer data consists of the data from the file, split into appropriate size chunks, and prepended by a header.
           The header consists of three fixed size parameters as shown in the list below.
         <ul>
-            <li>uid: 8 bytes. A unique identifier for this file transfer session.</li>
+            <li>uid: 4 bytes. A unique identifier for this file transfer session.</li>
             <li>messageNo: 1 byte. Starting at zero and increasing by one for each file chunk that is transferred.
             Maximum value is 254.</li>
             <li>file chunk size: 4 bytes. The size in bytes of this message, including the header size.</li>
@@ -1872,7 +1872,7 @@ <h2>File Transfer</h2>
   "value": {
     "name": "privateMap.kml",
     "hash": "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
-    "uid" "MTIzNDU2Nzg5MA=="
+    "uid" "2d878213"
   }
 }
           </code></pre>
@@ -1883,7 +1883,7 @@ <h2>File Transfer</h2>
         The client message on the data channel consists of a concatenation of the header and the file chunk.
         The server response on this contains a concatanation of the three parameters shown below.
         <ul>
-            <li>uid: 8 bytes. The identifier from the received message.</li>
+            <li>uid: 4 bytes. The identifier from the received message.</li>
             <li>messageNo: 1 byte. The message number from the received message.</li>
             <li>status: 1 byte. Indiates whether the message was correctly received or not.
           The value zero indicates that it was correctly received, while a non-zero value indicates that it was not.</li>
@@ -1906,7 +1906,7 @@ <h2>File Transfer</h2>
   "data": {
     "path": "Vehicle.Cabin.DashCam.Clip", 
     "dp" {
-      "value": {"name": "dashCamClip.mp4", "hash": "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "uid" "MTIzNDU2Nzg5MA=="},
+      "value": {"name": "dashCamClip.mp4", "hash": "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed", "uid" "2d878213"},
       "ts": "2024-08-20T11:30:00Z"
     }
   }
@@ -1915,7 +1915,7 @@ <h2>File Transfer</h2>
         If the GET request on the control channel receives an error message then the client shall not issue any messages on the data channel.
         Client messages has the same format as the server messages in the file download scenario,
         and as in that case it refers to the previously received message from the server.
-        The client must issue an initial message of this ype to trigger the server to respond,
+        The client must issue an initial message of this type to trigger the server to respond,
         in this first message the message number is set to 255 (all bits set to one).
         The client shall send a final message after receiving the last message from the server.
         If the status is set to zero the server shall respond with only the header from its last message.<br>
@@ -1925,10 +1925,9 @@ <h2>File Transfer</h2>
         If they differ the received file is likely corrupt.<br><br>
         A client may terminate a file download session on the data channel by sending only the header by setting the message number to 255, 
         the chunk size to zero, and the last message to non-zero, on which the server shall respond with status set to zero.<br>
-        A file upload session is terminated by the client by not issuing a message with both the message number and the status set to 255.<br>
-        The node type for the file resource MUST be "file".
-        This node type has a fixed datatype,  a struct with the members "name", "hash", and "size",
-        c. f. the HIM specification for the "file" node type definition.
+        A file upload session is terminated by the client by issuing a message with the message number set to 255 and the status set to non-zero.<br>
+        The node type for the file resource MUST be "actuator" for the download case and "sensor" for the upload case.
+        This node must have a fixed datatype,  a struct with the members "name", "hash", and "size".
           </p>
         <h3>Data channel realization</h3>
         <p>