Rainer: > In the light of this sum-up, I propose the following compromise: > > - we will continue to use the rfc 3339 timestamp in its > unmodified way > - we will ignore that RFC 3339 calls for timesync (because > we can't ensure it) > - there will be NO header field indicating the reliability > of the time flag > - there will be an optional structured data element which > allows to specify the timestamp reliability in all three > cases. If it is absent, it is assumed that the timestamp is > correct. If an implementor has a good indication this may > not be the case, his implementation SHOULD write the > respective element indicating this
This could be an ok compromise. But some clarification is still needed. 1. What is "timestamp is correct"? Left to implementation to decide? I am fine with that, if we can wordsmith it. 2. I am concerned about the "SHOULD" in the above. I think when implementation does have good indication that time is wrong it MUST provide a structured element to indicate this. It is still kinda voluntary because the implementation may not have a "good indication" or may have its own definition of "wrong" time. 3. What do devices which have no time put in the timestamp? Anything? I understand they will provide the structured element (MUST), but why not recommend what they should put in the timestamp instead of leaving it up to them to invent a convention? 4. Do we want to make a distinction between non-authoritative time and unknown time? Separate structured element? I know this has been a big thread. But there is a lot of intricate issues to deal with here. The biggest problem, like you indicated, is that our protocol is designed for a an environment which is not RFC 3339 compliant. Anton.