ORBit - CORBA TimeService
-------------------------

This is an implementation of the CORBA TimeService (formal/97-12-21).
The orbit-time-server provides the CosTime::TimeService interface.
and the orbit-timerevent-server provides the CosTime::TimerEventService
interface.

Before using the CORBA TimeService you should have a look to
Appendix C of the specification. There are some explanations of
how to protect against proxy related inaccuracies and how to transmit
time over a wire. 

To understand the origin of the TimeService in general you should have
a look at the OSF DCE Distributed Time Service (DTS) specification. 
For example the meaning of Tdf and Inaccuracy are described in more detail
there. See Appendix E of the TimeService specification for the references.

Secure Time:
------------
  The spec states that the implementation must make clear how the
  conformance for providing secure time is reached. See "Unclear Issues"
  for information about this topic.


Helper Functions:
-----------------
  The UTC format is quite unhandy so the TimeHelp files contain several
  functions to deal with UTC in a more natural way.


Unclear issues: 
---------------
The spec has some points where the intention of the authors is not always 
as clear as it should be. The following issues address those uncertainties.

1. As far as I undestood the criteria of Appendix A.2 of the specification
  addresses requirements which are actually out of scope of the Time Service
  implementation.
  The following criteria must be followed in order to reach conformance to 
  the specification (see the Appendix A.2 for the exact text):

  a. Administration of Time
     Only adminstrators are allowed to manipulate time related settings
     on the machine where the Time Service is running.
  b. Protection of Operations and Mandatory Audits
     All the operations of the undelying trusted time service must be
     protected against unauthorized invocation and audited.
  c. Synchronization of Time
     If the underlying time service is synchronized over the network, 
     this service must guarantee that the transmitted timestamps remain
     valid.

  Problem: if the implementation does not need to deal with the issues of
  secure time directly, then there is no difference in the universal_time()
  and the secure_universal_time() operations.
  Solution: Provide a parameter to the service to indicate on startup
  of the server that the underlying service is secure, e.g.
    orbit-time-server --secure

2. 14.2.5, 14-11, Operation spans()
  "... The exception CORBA::BAD is raised if the UTO passed is invalid."

  Problem: I did not find an explanation for the UTO being invalid.
  The same problem came up with a TIO being invalid for the Operation 
  overlaps, but in the description for the Operation new_interval I 
  found an explanation that a TIO is invalid if the lower_bound is 
  greater than the upper_bound.
  
  Hints for a Solution: The description for the Operation new_universal_time
  states that a CORBA::BAD_PARAM exception is raised if the inaccuracy
  is out of range. But this statement just leads to another problem: What 
  does it mean for the inaccuracy to be out of range ?

  I would assume that an UTO is invalid if there is a wrong value for
  the Inaccuracy member. The inaccuracy seems to have the same meaning
  in the DCE Distributed Time Service (DTS) specification. 
  An UTO is invalid if the inaccuracy touches the lower or the
  upper bound of the data type range, i.e. 
    time - inaccuracy < 0   or   time + inaccuracy > 0xFFFFFFFFFFFFFFFF
  But this could be treated by setting the lower bound to zero or to
  0xFFFFFFFFFFFFFFFF respectively.
  For the special case of the Operation spans() the UTO could be treated
  as invalid if the inaccuracy is zero, because without an inaccury
  we can not represent the UTO as an interval, although the algorithm
  should be able to treat an "interval" being just one point.. 

  FIXME: Uni Bibliothek Trier DCE DTS spec !!!!!!!!!

3. 14.1.5, 14-4, Conformance Points 
  "An implementation of the CosTime module in which the universal_time
  operation always raises the TimeUnavailable exception is not
  acceptable for satisfying this conformance point."
  I think this should be read as:
  "An implementation of the CosTime module in which the *secure*_universal_time
  operation always raises the TimeUnavailable exception is not
  acceptable for satisfying this conformance point."

4. The spec should be more precise about how to collect and how to treat the
  error value (inaccuracy), especially for the operations absolute_time().
  When we get the current time for the time provider, we will always get an
  error, but the object itself has already an error for the contained time.
  Normally those values should be added as well. (?)

5. The operation TimeService_universal_time() raises an TimeUnavailable 
  exception if the trusted time service fails. But the operation 
  UTO_absolute_time() also tries to get the current time from the trusted
  time service. What if this goes wrong, the spec just mentions the 
  CORBA::DATA_CONVERSION exception if the upper limit is exceeded.

6. The operation TIO_time() returns a UTO but nothing is said about
  the timezone. I assume it should be set to zero in this case.

March 2000
  Michael Rumpf

