Re: [calsify] New Timestamp Draft

[Eliot Lear <[e-mail]>]

Hi Bron,

Thanks for taking my views into account.  Please see below.

> On 24 Jan 2021, at 11:53, Bron Gondwana <[e-mail]> wrote:
> 
> I'll ask you the same question I asked Ned, which is "do you object to this work being taken up by the IETF at all, or just to it obsoleting 3339?"

I think it depends on what you mean by “this”.  If “this” means modifying the 3339 timestamp format directly, then yes, I would object - at this point (maybe not later, but see below).  If “this” means finding a means to provide additional information to a consumer relating to the context of timestamp, then no I would not object to the IETF taking it on.  In other words, I am not convinced that the current draft is the correct starting point, which is why I recommended that this be aired in DISPATCH.

I hinted above at a potential way forward for Ujjwal: if we take a step back and separate the information model from its representation I think things would go a little better.  For instance, the draft defines two new information elements: time zone and a calendar tag. Discussing those two extensions (or any others) and their value constraints may be helpful.  Then discussing how to represent them in different environments may be helpful as well.  In this way, you make use of at least one existing architectural building block while creating one of your own.

You have a lot of tools in your toolbox.  You could easily create a JSON array that represents that model that includes a 3339 timestamp and whatever additional information you believe appropriate.  You could use YANG or your favorite way to do that.  If you use YANG, you get an XML serialization for free as well.  And once you’ve done that for JSON you’ve also pretty much picked up CBOR, which is nice.  Pick your own favorite representation.  The nice thing about YANG is that all the O&M people will give you love for that.

If people want to add that object to logs, I imagine that some day SYSLOG will get around to being “JSONified” and/or “CBORified” (there were already attempts at XML… sigh).  And if people using the existing SYSLOG format want to include that information today using the existing format, they can just pick up the information elements and represent them in the log components that they control.

You could do all of this without updating 3339.  Still, there may be a need to update 3339, but it has to be done quite carefully, with all ramifications, side effects, and alternatives being considered.  Also, I could easily imagine both an update to 3339 to do things like obsoleting two-digit years and a new draft to handle extensions a’la the above.


> 
> I will also point out that for all that we've talked about making the IETF more welcoming to newcomers, this has been a really unfriendly experience for Ujjwal.  Maybe that's my fault, but I'm sorry Ujjwal for misleading you if so.

I apologize too if my comments are late, but this is pretty foundational.


> I did raise that this work was coming in the "any other business" at IETF110's DISPATCH, but without a draft there was very little guidance.  Indeed the minutes of last dispatch say:
> 
> Bron Gondwana: RFC3339 extension
> * Javascript notation format is looking for a standard serialisation.
> 
> Harald Alvestrand:
> * We should have done this in the 90s!  It was a mistake not to do it then.
> 
> Neil Jenkins:
> * we do need a serialisation format
> 
> Where to discuss: calsify or tzdata lists, but probably calsify is best.
> 
> You can watch a video of the exact discussion here: https://youtu.be/d871MoUgAKU?t=6418 <https://youtu.be/d871MoUgAKU?t=6418>
> 
> ...
> 
> Regardless, it appears that the right next venue for this document is DISPATCH at IETF110.

Yes, please.  Not that I object to this being discussed here prior to adoption, so long as the chairs don’t mind (that’s entirely your call and entirely not mine).

Eliot