Re: [calsify] New Timestamp Draft

[Alexey Melnikov <[e-mail]>]

Hi,

On 25/01/2021 21:07, Barry Leiba wrote:

> First, everyone, meet Francesca Palombini (added on CC), who will be
> your new AD starting in March.
Wellcome Francesca!
> 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.
I am sorry I was not paying enough attention to this topic earlier, but 
if you are looking for more feedback, this is my 2p:
> 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.
No. I would rather leave RFC 3339 as is, for reasons that Ned and Eliot 
have stated.
> Do we need a standard JSON wrapper around what
> 3339 specifies, either as a stop-gap or as a permanent solution?

Yes, I can see this work as being useful. But I don't think we need to 
replace RFC 3339, an extension (or wrapper) which just defines extra 
stuff is going to be much quicker to complete and will have less resistence.

I think draft-ryzokuken-datetime-extended is a good starting point for 
this effort, once a lot of original RFC 3339 text is deleted from it.

Best Regards,

Alexey

> 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