Re: [art] [saag] Date formats: RFC3339 vs. RFC 5322

[Benjamin Kaduk <[e-mail]>]

On Tue, Apr 13, 2021 at 03:01:02PM -0500, Nico Williams wrote:
> On Tue, Apr 13, 2021 at 12:30:21PM -0700, Paul Hoffman wrote:
> > Given that the date in that section of that draft is meant to be machine
> > parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad idea,
> > given the existence of RFC 3339.
> 
> I mean, strptime() can handle both, and since everything is written in C
> (which is why we so badly need security.txt!), that's enough.  But yes,
> ISO 8601 is much easier to parse.  And it will be even easier to compare
> dates if security.txt ends up using Zulu time, since then plain string
> comparison (even memcmp()!) is enough.
> 
> Thinking about implementation... I suddenly wonder why security.txt
> should have expiration instead of a TTL.  I'm pretty sure what's really
> intended is that I not cache security.txt files too long so that they
> can be updated.  Indeed, sections 3.5.5 and 6.3 make it clear that this
> is about caching.
> 
> An optional publication time (ISO 8601), and a required TTL measured in
> hours or days would be more than sufficient, and maybe superior to a
> notAfter.  Unless the point of `Expires` is also to force the publisher
> to keep security.txt up to date.

Yes, that.
We got a lot of LC feedback that (okay, I might be exaggerating for effect)
the future Internet would be littered with piles of stale security.txt
files to the extent that the mechanism would be rendered useless due to the
expectation of stale content.  Adding "Expires" serves as something of a
"dead-man's switch" that lets stale content age out relatively gracefully.

> Implementation-wise, I see a few ways in which I would handle `Expires`
> information:
> 
> 1) Comparison.  E.g., to determine if a security.txt is stale, or to
>    sort/index/search archived security.txt files, in which case I'd have
>    two choices:
> 
>    1a) if the format is ISO 8601 zulu, then format current time then
>        string compare,
>    1b) parse the `Expires` into local time of day form and compare to
>        current time.
> 
>    (1a) is simpler, but only works for ISO 8601 Zulu times.
> 
> 3) Authoring/production of security.txt files, where I only need to
>    format time, not parse it.
> 
> Clearly it's easier to only have to format time and never have to parse
> it.
> 
> That said, strptime() and similar are widely available and easy enough
> to use, so I do think there's an readability argument to make.  But ISO
> 8601 is still easier to read than RFC 5322 time, especially for
> non-English speakers.

And I think the authors have a clear answer for what to do here.

Thanks to everyone for the feedback.

-Ben