Re: [calsify] New Timestamp Draft

[Shane Carr <[e-mail]>]

Correction: item 2 should say "standalone timestamp syntax", not
"standalone timezone syntax".

On Mon, Jan 25, 2021 at 11:29 PM Shane Carr <[e-mail]> wrote:

> 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
>>
>