Standards for Technology in Automotive Retail

 Home -  News Feed 

7.2. Discussions

7.2.1. Trusted Timestamp Services

The possible use of third party Trusted Timestamp Services was discussed and rejected as not being necessary for STAR Transport given that current STAR Management and Auditing requirements are sufficient to guarantee accurate message timestamps.

Currently, STAR Transport Management Guidelines REQUIRE the use of NTP (Network Time Protocol) which guarantees participating system times are accurate and STAR Management and Auditing requirements specify UTC/GMT Timestamps for in-transit messages which allows for clear and common interpretation of Timestamp values without the need to compensate for Time Zones or Daylight Savings Time.

7.2.2. Timestamp Format

Discussion centered on the difference between UTC with offsets and UTC without offsets. Consensus was that UTC without offsets is a desirable and beneficial common format. When two logs, such as the sending and receiving log must be compared, a common universal format that does not need interpretation due to time-zone offsets is beneficial, especially if a human being is being required to manually analyze the logs.

7.2.3. Key Data Fields

Discussion was that there are a small number of key fields critical to Auditing, and that Logging systems MUST save these values and enable queries based on these values, or at least be able to display the values. Initial key fields identified are Datetime, MessageID, Hostname and Activity (i.e., the service name or web method).

7.2.4. Associating Messages with Business Transactions

Discussion was that Logging systems must be capable of associating unique messages with unique business transactions. Logging systems may key off specific STAR Transport Web Services or ebMS fields including but not limited to MessageID and ConversationID. Further discussion was that it is the responsibility of the application or the transport to generate globally unique message IDs for every message.

7.2.5. Message IDs through Intermediaries

Messages that are opened by an intermediary or repackaged messages REQUIRE new IDs. The reasoning behind this is that a message ID is associated with the integrity of that message. By opening a message, a party effectively “accepts” that message and another message with a new ID is then created to pass on the content, even if the content has not been altered. If the message is not opened or repackaged the message ID can be passed along with the message. Intermediaries are responsible for tracking transformations or mapping of message IDs for messages that are opened.