Subject: [Sedate] Distinguishing "optional extra" vs "you need to understand this to process the date accurately" extensions

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 10 Dec 2021 00:04:34 +1100

Topic for discussion today/tomorrow!

I think draft-ryzokuken-datetime-extended <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>-02 has really good wording about "this stuff is out of scope, but could be handled in a future extension", but it raises the difficulty of how a receiver who doesn't know about the extension can know that it shouldn't trust the datetime as given.

So I wonder if we need a syntax to say "if this extension is not recognized by the receiving system, it SHOULD throw an error and MUST NOT expect the date to be exact" - either a reserved namespace for such extensions, or some other syntactical sugar.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Dec 2021 15:59:46 +0100

> So I wonder if we need a syntax to say "if this extension is not recognized by the receiving system, it SHOULD throw an error and MUST NOT expect the date to be exact" - either a reserved namespace…

Protocols typically have a way to distinguish “critical” (or “must-understand”) options from “elective” options.  Sometimes, the distinction is baked into the option code, sometimes there is separate place (which also allows the same option to be used in both ways).  Our syntax should provide an easy way to do the latter, as in:

   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca=hebrew]
(Elective, ignore option if not understood)

   1996-12-19T16:39:57-08:00[America/Los_Angeles][u-ca!hebrew]
(Critical, must understand/must reject date if not understood)

Well, we need better examples...

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Dec 2021 11:05:44 -0500

--On Thursday, December 9, 2021 15:59 +0100 Carsten Bormann
<[email-masked]> wrote:

>> So I wonder if we need a syntax to say "if this extension is
>> not recognized by the receiving system, it SHOULD throw an
>> error and MUST NOT expect the date to be exact" - either a
>> reserved namespace for such extensions, or some other
>> syntactical sugar.
> 
> Protocols typically have a way to distinguish "critical"
> (or "must-understand") options from "elective"
> options.  Sometimes, the distinction is baked into the option
> code, sometimes there is separate place (which also allows the
> same option to be used in both ways).  Our syntax should
> provide an easy way to do the latter, as in:
> 

Carsten,

Using your examples and adapting your syntax (purely as
examples), would you also expect/allow

    1996-12-19T16:39:57-08:00[!America/Los_Angeles][u-ca=hebrew]
How about 

2022-12-19T16:39:57!-08:00[!America/Los_Angeles][!u-ca=hebrew]
which might mean "that time, somewhere"?

:-(
Standing one the edge and looking down the slippery slope here.

best,
   john

---

From: Justin Grant <[email-masked]>
Date: Thu, 9 Dec 2021 11:55:50 -0800

For the core timestamp format (from RFC 3339) and for time zone annotations
(which already exist in java.time and similar libraries like Noda Time for
.NET), adding a "this is required" character would break backwards
compatibility. I'd be somewhat concerned about formats like
2022-12-19T16:39:57!-08:00[!America/Los_Angeles] for that reason.

For new extensions like calendar without prior art, it seems more
reasonable to have an indicator of what's required vs optional. That said,
I'd be concerned that senders might not have a clear understanding of what
the receiver is going to do with the data-- so the sender may have to guess
about whether to include the "!" or not. Or in the case of storing strings
in a database, the sender might not know who's going to be using that data
in the future, and for what purpose. In that case, the sender won't really
know whether to include the "!".

Unless we can define a really clear, deterministic way for senders to know
whether to include the "!" or not, then I worry that we'd end up with a
somewhat-random patchwork of usage where some senders add the "!" and some
don't for the same use case.

Best,
Justin

On Thu, Dec 9, 2021 at 8:06 AM John C Klensin <[email-masked]> wrote:

> Sedate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sedate
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 10 Dec 2021 07:01:23 +1100

On Fri, Dec 10, 2021, at 06:55, Justin Grant wrote:
> For the core timestamp format (from RFC 3339) and for time zone annotations (which already exist in java.time and similar libraries like Noda Time for .NET), adding a "this is required" character would break backwards compatibility. I'd be somewhat concerned about formats like 2022-12-19T16:39:57!-08:00[!America/Los_Angeles] for that reason.
> 
> For new extensions like calendar without prior art, it seems more reasonable to have an indicator of what's required vs optional. That said, I'd be concerned that senders might not have a clear understanding of what the receiver is going to do with the data-- so the sender may have to guess about whether to include the "!" or not. Or in the case of storing strings in a database, the sender might not know who's going to be using that data in the future, and for what purpose. In that case, the sender won't really know whether to include the "!".

The point is to only have the '!' on things that are required to accurately interpret the time.   I don't think it should be an optional field where you can either have it or not, it should be for things like "relativity offset" where if you're traveling really fast and a long way from Earth then you need to know that in order to accurately align values.  It's not "you need to know hebrew to understand this timepoint" it's "you won't be able to accurately calculate the timepoint unless you understand this.

> Unless we can define a really clear, deterministic way for senders to know whether to include the "!" or not, then I worry that we'd end up with a somewhat-random patchwork of usage where some senders add the "!" and some don't for the same use case.

Not for my initial suggestion - where it's not optional - it's either a datapoint which has it, or not.

Bron.

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Dec 2021 22:45:59 -0500

--On Thursday, December 9, 2021 11:55 -0800 Justin Grant
<[email-masked]> wrote:

> For the core timestamp format (from RFC 3339) and for time
> zone annotations (which already exist in java.time and similar
> libraries like Noda Time for .NET), adding a "this is
> required" character would break backwards compatibility. I'd
> be somewhat concerned about formats like

Maybe one solution to that would be to flag the stuff that can
safely be ignored rather than trying to flag newly required
things.  I haven't thought through enough cases to be convinced
that would work, but the "what to flag" decision can be made
either way.  And, as I commented on chat, if we are going to
make the distinction, the syntax used to make it should be much
more, as the saying goes, in-your-face than an exclamation mark
next to a square bracket.  A different type of bracket, two or
three such marks, or something else would do but, visually, "[!"
is too easy to lose.  

And, despite the decision that this things are for computers,
not people, we have ample experience to predict that people will
end up looking at them, even if only in debugging or other odd
cases.

> For new extensions like calendar without prior art, it seems
> more reasonable to have an indicator of what's required vs
> optional. That said, I'd be concerned that senders might not
> have a clear understanding of what the receiver is going to do
> with the data-- so the sender may have to guess about whether
> to include the "!" or not. Or in the case of storing strings
> in a database, the sender might not know who's going to be
> using that data in the future, and for what purpose. In that
> case, the sender won't really know whether to include the "!".

Yep.  See above.

> Unless we can define a really clear, deterministic way for
> senders to know whether to include the "!" or not, then I
> worry that we'd end up with a somewhat-random patchwork of
> usage where some senders add the "!" and some don't for the
> same use case.

No matter which one is marked, "this can safely be treated as
noise" and "if you don't understand this, don't try to use the
string or even guess what it might mean" is, IMO, a rather clear
distinction. I think things get complicated only if one inserts
"maybe", "usually", or "in case you are confident that you have
a good guess" into one of those sentences.

best,
   john