Re: [Sedate] Paul Wouters' No Objection on draft-ietf-sedate-datetime-extended-10: (with COMMENT)

[Philip Chimento <[e-mail]>]

On 2023-10-18 10:59, Carsten Bormann wrote:
>> So what about this example:
>> 
>>      2022-07-08T00:14:07+01:00[Australia/Brisbane]
> 
> This example cannot be evaluated with respect to the sentence:
> 
>    Where consistent interpretation
>    between multiple actors is required for security purposes (e.g.,
>    where timestamps are embedded as parameters in access control
>    information), only such extensions can be employed that have a
>    defined resolution of such inconsistent data.
> 
> … because we don’t know the context.
> If the context is “open the front door to Fort Knox at exactly this instant in time”, clearly we need a defined resolution for such an inconsistency.
> (If the context is “A photo from the sunset in Brisbane at this instant in time”, the photo may not require resolution for using it as wallpaper; it can still be useful with the unresolved inconsistency.  The context could also be used to identify the time offset and zone information as bogus, because there can’t have been a sunset at Brisbane local time 00:14 or UTC+1 time 00:14.)
> 
> Section 1.1 has this to offer:
>    While the information available in an IXDTF string is not generally
>    sufficient to resolve an inconsistency, it may be used to initiate
>    some out of band processing to obtain sufficient information for such
>    a resolution.
> 
> Initiation of Out-of-band processing would probably be the desirable outcome in the Fort-Knox example, while a red asterisk on some metadata display would be fine for most photo applications.

As an example of a 'defined resolution' (or well-understood and shared
resolution as Carsten has rephrased it), the ECMAScript Temporal API has
a parameter that allows the caller to specify which resolution they want
in case of this inconsistency.

Further reading: [1]

Examples:

openFortKnoxTime =
Temporal.ZonedDateTime.from('2022-07-08T00:14:07+01:00[Australia/Brisbane]',
{ offset: 'reject' });

This throws an exception so that the caller knows the input is invalid
and needs to be corrected out-of-band.

photoTime =
Temporal.ZonedDateTime.from('2022-07-08T00:14:07+01:00[Australia/Brisbane]',
{ offset: 'use' });

This corrects the time to 2022-07-08T09:14:07+10:00[Australia/Brisbane],
which is what the caller should do if they want to assume that the
2022-07-08T00:14:07+01:00 part indicates the correct instant in time but
the match between time zone annotation and UTC offset is wrong. (There's
also a different option for assuming that the wall-clock time is correct
but the UTC offset is incorrect.)

[1] https://tc39.es/proposal-temporal/docs/zoneddatetime.html#from

Best regards,
-- 
Philip Chimento
Igalia, S.L.