View Issue Details

IDProjectCategoryView StatusLast Update
000461610000-004: ServicesApi Changepublic2020-03-04 22:26
ReporterHannes Mezger Assigned ToPaul Hunkar  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Summary0004616: View Services/View Minimum Continuation Point 01/Err-010.js
Description

The test expects the call to fail due to a null timestamp in the RequestHeader.

In part 4, table 170, the spec states that the timestamp in the RequestHeader " is only used for diagnostic
and logging purposes in the server".

For me this means that the server doesn't have to check the timestamp and that the test can not expect the call to fail.

Additional Information

Same applies to:

  • View RegisterNodes/Err-009.js and Err-014.js
  • View TranslateBrowsePath/Err-024.js
TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0001449 closedMatthias Damm 10000-004: Services RequestHeader.Timestamp (utcTime) - Clarification needed 
has duplicate 0004706 closedPaul Hunkar Compliance Test Tool (CTT) Unified Architecture Expected BadInvalidTimestamp 
related to 0004326 closedAlexander Allmendinger CTT UA Test Case BadInvalidTimestamp in View Services -> View TranslateBrowsePath -> Err-024.js 

Activities

Alexander Allmendinger

2019-02-14 15:49

developer   ~0009890

As the specification askes to verify the timestamp in Part 6 Section 6.3 of the spec for security reasons, this sentence needs to be changed.
Creating a MantisIssue for Part 4.

Paul Hunkar

2019-02-14 15:54

developer   ~0009891

The group felt that Part 4 should remove the word "Only" - the TimeStamp is also used for security

Matthias Damm

2019-02-20 17:04

developer   ~0009897

Last edited: 2019-02-20 17:35

We added this sentence in Part 4 to make clear that a service request is NOT rejected because of a time difference and not synchronized clocks.
The sentence was added in OPC UA 1.02 (see Mantis issue 0001449)

We added this sentence since such test was in earlier versions of the CTT and the UA WG decided that such tests make no sense.

The text in OPC UA Part 6 - 6.3 is not very concrete. The only shall talks about a configuration parameter. There is no definition what an application (client or server) should do if it detects that the times are not synchronized.

As long as we do not have a general concept for time synchronization, we are not able to enforce such harsh behaviour like rejecting service requests. There should be a better way to indicate suceh a problem that "you are not longer able to talk to me".

Matthias Damm

2019-02-20 17:37

developer   ~0009899

Please assign this back to the CTT. No change in Part 4 since this sentence was added intentionally (see comment above with reference mantis issue 0001449)

Bernd Edlinger

2019-02-21 20:41

reporter   ~0009902

It is sufficient to check that the request time stamp is non-zero.
At least as the test case is currently written.

That is not too difficult to implement on the server side.

But I agree that it would be very problematic when
more than just non-zero timestamp in the request header
has to be checked in the server.

Matthias Damm

2020-03-04 22:25

developer   ~0011675

We can only check the timestamp in the Service Request Header if we have mandatory time synchronization.

Jim Luth

2020-03-04 22:26

administrator   ~0011676

Agreed to no-fix in Dallas meeting.

Issue History

Date Modified Username Field Change
2019-02-11 14:54 Hannes Mezger New Issue
2019-02-11 14:55 Hannes Mezger Additional Information Updated
2019-02-14 15:42 Alexander Allmendinger Assigned To => Paul Hunkar
2019-02-14 15:42 Alexander Allmendinger Status new => assigned
2019-02-14 15:49 Alexander Allmendinger Note Added: 0009890
2019-02-14 15:50 Paul Hunkar Project Compliance Test Tool (CTT) Unified Architecture => 10000-004: Services
2019-02-14 15:50 Paul Hunkar Category 4 - Test Case Definition => Api Change
2019-02-14 15:54 Paul Hunkar Note Added: 0009891
2019-02-20 17:04 Matthias Damm Note Added: 0009897
2019-02-20 17:22 Matthias Damm Note Edited: 0009897
2019-02-20 17:25 Matthias Damm Relationship added related to 0004326
2019-02-20 17:29 Matthias Damm Relationship added related to 0001449
2019-02-20 17:35 Matthias Damm Note Edited: 0009897
2019-02-20 17:37 Matthias Damm Status assigned => feedback
2019-02-20 17:37 Matthias Damm Note Added: 0009899
2019-02-21 20:41 Bernd Edlinger Note Added: 0009902
2019-04-05 15:10 Paul Hunkar Relationship added has duplicate 0004706
2020-03-04 22:25 Matthias Damm Status feedback => resolved
2020-03-04 22:25 Matthias Damm Resolution open => no change required
2020-03-04 22:25 Matthias Damm Note Added: 0011675
2020-03-04 22:26 Jim Luth Status resolved => closed
2020-03-04 22:26 Jim Luth Note Added: 0011676