Re: [calsify] New Timestamp Draft

[Shane Carr <[e-mail]>]

Thanks everyone for the thoughtful responses.

At this point, I have seen three general types of concerns over
Ujjwal's proposal:

1) Concerns that we need to spend more time exploring the space before
jumping into a solution
2) Concerns over compatibility with systems that want a standalone timezone
syntax without Ujjwal's annotations
3) Proposition that we should standardize a JSON/YANG schema before a
string syntax

My responses:

1) Ujjwal's proposal is the result of quite a bit of work within ECMA-TC39
and liaising with some folks in the Unicode Consortium.  I worry that
chartering a new working group would duplicate much of the work that has
already gone into this proposal (not to mention setting ECMA back further).

2) Two very clear paths forward have been presented: publish the proposal
as a new RFC, and then either keep 3339 the way it is, or publish a
successor to 3339 with 6-digit years but no annotations.

3) I discussed earlier why I feel a string syntax is warranted.  I'm happy
to continue this discussion if we can narrow it down to this point of
contention.

Shane


On Mon, Jan 25, 2021 at 3:07 PM Barry Leiba <[e-mail]> wrote:

> First, everyone, meet Francesca Palombini (added on CC), who will be
> your new AD starting in March.
>
> I do have to agree with Eliot that obsoleting 3339 is well out of
> charter for calext.  What you quote below from what you said in
> dispatch, "Javascript notation format is looking for a standard
> serialisation", is not the same thing as "revising and obsoleting RFC
> 3339".  As Eliot points out, there are ways to include extra
> information in jCalendar, for example, without changing the basic
> date/time strings that are used in many places.  Changes to the 3339
> date/time strings will have ramifications all over the Internet, and I
> think that needs its own working group and a lot of publicity to make
> sure we're getting "everyone" who cares about it, rather than doing it
> where people think we're only dealing with calendaring protocols.
>
> I *am* sorry if this has been frustrating, unfriendly, or otherwise
> unpleasant for Ujjwal, and I'm quite sensitive to that.  I'm happy to
> help in any way I can, as I know Bron and Eliot (and Francesca) are.
> But we can't just handle this document in an inappropriately light
> way... the effect will be too far-reaching, even if exactly the
> changes that Ujjwal's draft suggests should turn out to be perfect.
>
> Do we think we should be chartering a working group to revise and
> obsolete RFC 3339?  If so, let's get a draft charter for that and get
> the process started.  Do we need a standard JSON wrapper around what
> 3339 specifies, either as a stop-gap or as a permanent solution?  Then
> maybe calext is the place to do that, and let's shift to working on
> that.
>
> Barry, ART AD
>
> On Sun, Jan 24, 2021 at 5:53 AM 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 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 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
> >
> > ...
> >
> > Regardless, it appears that the right next venue for this document is
> DISPATCH at IETF110.
> >
> > Regards,
> >
> > Bron.
> >
> > On Sun, Jan 24, 2021, at 21:32, Eliot Lear wrote:
> >
> > Bron,
> >
> > I’m sorry, but I have both substantive and procedural problems with you
> moving forward like this.  Let me start with the procedural.  This work
> isn’t in calext’s charter.  You are specifically chartered to tackle
> several extensions to the iCalendar format, and that is it.  This is not an
> extension to that format.  This is a change to a standard that is used
> extremely broadly.
> >
> > And this leads me to the substantive concern: this change is backward
> incompatible with  3339.  The ABNF in 3339 is clear: the stamp ends
> "time-offset" ("Z" / time-numoffset).  Adding “suffix" blow up in any
> yacc/bison-based parser and who knows what else.  Just imagine all the
> perl, awk, php, and python that whacks this stuff.
> >
> > In a great many cases, there is no means to negotiate the extension.
> Let me give you two examples:
> >
> > Logging software commonly uses 3339 both for generation and for parsing,
> and the parsers themselves are notoriously fragile to the point that I do
> not believe any of them would entertain any changes to 3339.  The ecosystem
> is so vast that there is no hope of enumerating it.  To test this, imagine
> what damage changing any other field to syslog would cause.
> > Calendaring software, though in a smaller ecosystem, will have older
> versions that may well fail to parse.
> >
> >
> > I am not saying that 3339 can never be updated, but before it is, it
> should be clear that (a) it is broadly needed, not just by calendaring, and
> (b) that there is reason to believe that the change will be broadly
> adopted, again not just by calendaring.  If it’s just the calendaring
> ecosystem, you have properties and parameters to use.
> >
> > Eliot
> >
> >
> > On 24 Jan 2021, at 04:15, Bron Gondwana <[e-mail]> wrote:
> >
> > The document is plenty complete enough for a call for adoption!  I shall
> do so now.
> >
> > You are exactly correct that it's possible to do further iteration after
> adoption.
> >
> > Thanks,
> >
> > Bron.
> >
> > On Fri, Jan 22, 2021, at 23:19, Ujjwal Sharma wrote:
> >
> > Hi Bron, CalExt Friends!
> >
> > I made a new revision of the draft, which shifts the focus to defining
> > the syntax/format and defers the standardization of the actual key-value
> > pairs to sibling organizations like IANA and Unicode Consortium.
> >
> > I'd love to hear your opinions on this version, which you can find at
> > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/,
> > which can be filed as issues on the GitHub repository or emailed to me
> > directly. In the meantime, I will address the remaining concerns/polish
> > issues like fixing the references section.
> >
> > How "complete" does the document need to be in order to initiate the
> > call for adoption? If the current version works, can we start it as soon
> > as possible? Of course, if my understanding of "adoption" is correct,
> > I'd be happy to iterate on the document further after the adoption by
> > the WG.
> >
> > Best,
> > Ujjwal
> >
> > On 14/01/2021 8.34 am, Bron Gondwana wrote:
> > > Sounds great.  Let me know :)
> > >
> > > When we do the call for adoption I'll also advertise the fact over to
> > > the wider IETF - probably dispatch and tzdata lists at least.
> > >
> > > Cheers,
> > >
> > > Bron.
> > >
> > >
> > > On Thu, Jan 14, 2021, at 13:48, Ujjwal Sharma wrote:
> > >> Thanks Bron!
> > >>
> > >> I'll make a few more changes, release a 01 version, ask for more
> > >> feedback and then let you know, hopefully by the end of this week.
> > >>
> > >> Ujjwal
> > >>
> > >> On 14/01/2021 7.03 am, Bron Gondwana wrote:
> > >> > I can do a call for adoption straight away if you like - the next
> > >> > meeting isn't for a couple of months.
> > >> >
> > >> > Bron.
> > >> >
> > >> > On Thu, Jan 14, 2021, at 05:24, Ujjwal Sharma wrote:
> > >> >> One question: given things move forward smoothly, how do I proceed?
> > >> >> Should I apply for this document to be adopted by the calext WG? I
> > >> >> suppose the fastest way to proceed is to present it at the next
> IETF
> > >> >> meeting?
> > >> >>
> > >> >>
> > >> >>
> > >> >> Ujjwal
> > >> >>
> > >> >> On 12/01/2021 4.03 am, Ujjwal Sharma wrote:
> > >> >> > Hi Calsify folks!
> > >> >> >
> > >> >> > I am sorry for the long delay, I got a little sidetracked
> working on
> > >> >> > other things, but I'm happy to inform you all that I have
> > >> something that
> > >> >> > resembles a first draft for the updated timestamps RFC.
> > >> >> >
> > >> >> > Here's where you can find it:
> > >> >> >
> > >> >> > Datatracker:
> > >> >>
> > >> > https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/
> > >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/>
> > >> >>
> > >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/
> > >> <https://datatracker.ietf.org/doc/draft-ryzokuken-datetime-extended/
> >>
> > >> >> >
> > >> >>
> > >> GitHub:
> https://github.com/ryzokuken/draft-ryzokuken-datetime-extended
> > >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>
> > >> >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended
> > >> <https://github.com/ryzokuken/draft-ryzokuken-datetime-extended>>
> > >> >> >
> > >> >> > I would request you all to take a look at it when you can and
> let me
> > >> >> > know what you think. You can file a GitHub issue or email me
> > >> directly.
> > >> >> >
> > >> >> > There's a few open discussions regarding the exact format and
> how the
> > >> >> > interaction with bodies like the Unicode consortium work, so
> > >> please feel
> > >> >> > free to send me your thoughts regarding that as well.
> > >> >> >
> > >> >> > Also, some references/bibliography is not perfectly functional
> yet
> > >> >> > because I am still relatively new to authoring RFCs using
> > >> Metanorma but
> > >> >> > I'm actively looking into it.
> > >> >> >
> > >> >> > Thanks and looking forward to hear from you,
> > >> >> > Ujjwal
> > >> >> >
> > >> >>
> > >> >> --
> > >> >> Ujjwal "Ryzokuken" Sharma (he/him)
> > >> >>
> > >> >> Compilers Hacker, Node.js Core Collaborator and Speaker
> > >> >>
> > >> >> _______________________________________________
> > >> >> calsify mailing list
> > >> >> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail]
> > >> <mailto:[e-mail]>>
> > >> >> https://www.ietf.org/mailman/listinfo/calsify
> > >> <https://www.ietf.org/mailman/listinfo/calsify>
> > >> >> <https://www.ietf.org/mailman/listinfo/calsify
> > >> <https://www.ietf.org/mailman/listinfo/calsify>>
> > >> >>
> > >> >
> > >> > --
> > >> >   Bron Gondwana, CEO, Fastmail Pty Ltd
> > >> >   [e-mail] <mailto:[e-mail]>
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > calsify mailing list
> > >> > [e-mail] <mailto:[e-mail]>
> > >> > https://www.ietf.org/mailman/listinfo/calsify
> > >> <https://www.ietf.org/mailman/listinfo/calsify>
> > >> >
> > >>
> > >> --
> > >> Ujjwal "Ryzokuken" Sharma (he/him)
> > >>
> > >> Compilers Hacker, Node.js Core Collaborator and Speaker
> > >>
> > >> _______________________________________________
> > >> calsify mailing list
> > >> [e-mail] <mailto:[e-mail]>
> > >> https://www.ietf.org/mailman/listinfo/calsify
> > >> <https://www.ietf.org/mailman/listinfo/calsify>
> > >>
> > >
> > > --
> > >   Bron Gondwana, CEO, Fastmail Pty Ltd
> > >   [e-mail]
> > >
> > >
> > >
> > > _______________________________________________
> > > calsify mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/calsify
> > >
> >
> > --
> > Ujjwal "Ryzokuken" Sharma (he/him)
> >
> > Compilers Hacker, Node.js Core Collaborator and Speaker
> >
> > _______________________________________________
> > calsify mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/calsify
> >
> >
> > --
> >   Bron Gondwana, CEO, Fastmail Pty Ltd
> >   [e-mail]
> >
> >
> > _______________________________________________
> > calsify mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/calsify
> >
> >
> > Attachments:
> >
> > signature.asc
> >
> >
> > --
> >   Bron Gondwana, CEO, Fastmail Pty Ltd
> >   [e-mail]
> >
> >
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>