security.txt now uses ISO8601 (sorta...)
By @edent
· 400 words · read ~243 times.
If you're unfamiliar, security.txt is a proposed Internet standard. The idea is simple, your website hosts a plain text file at /.well-known/security.txt which tells people who your security contacts are, what your vulnerability disclosure policies are, where your PGP key is, etc. Useful!
Because it is in draft, people can comment on it to make things better. So I did.
I noticed that all the dates in the standard used RFC5322 datetimes. They look like this:
Thu, 8 Apr 2021 12:34 +0100
I'm not a big fan of that style. The named entities are English only. Not everyone on the World Wide Web speaks English. For machine readability, I think it's also a bit weak. Lots of whitespace, and not an easy string to regex or identify.
So I suggested that it moved to ISO8601 - everyone's favourite standard! It defines timestamps as being in descending order of precision in a way which reduces ambiguity and balances human- and machine-readability. The above timestamp is rendered like this:
2021-04-15T12:34+0100
Now, there are problems with ISO8601. It is a paid-for standard, so isn't completely open. I suggested using a profile of it - RFC3339
That simplifies ISO8601 for use in internet protocols by leaving out infrequently used levels of accuracy.
The complete set of date and time formats specified in ISO 8601 is quite complex in an attempt to provide multiple representations and partial representations... Internet protocols have somewhat different requirements and simplicity has proved to be an important characteristic. In addition, Internet protocols usually need complete specification of data in order to achieve true interoperability. Therefore, the complete grammar for ISO 8601 is deemed too complex for most Internet protocols. The following section defines a profile of ISO 8601 for use on the Internet. It is a conformant subset of the ISO 8601 extended format. Simplicity is achieved by making most fields and punctuation mandatory.
The suggestion has been accepted and the latest draft will specify RFC3339 timestamps.
Next time someone argues against 8601 for being a closed standard, just use RFC3339 instead.
