Re: [saag] Last Call: <draft-foudil-securitytxt-08.txt> (A Method for Web Security Policies) to Informational RFC

[Carsten Bormann <[e-mail]>]

On Dec 28, 2019, at 18:58, S Moonesamy <[e-mail]> wrote:
> 
> Have the authors considered line limits given that the specification defines a machine-parsable format?

Don’t do that (putting in artificial limitations into a new spec can sometimes be faintly legitimized by legacy considerations, such as in MIME 8bit, but usually only has negative consequences).

> Why does the robustness principle require capital letters? (Section 4)?

I don’t see a reference to RFC 1123 there.  I think the BCP14 language in that section is justified, with the possible exception of

   Any directives registered
   via that process MUST be considered optional.

(What?  Considered by whom?  What does “considered optional” actually mean?  Does “that process” include the directives registered by the proposed document?)

.oOo.

Obviously, I’m not a fan of standardizing yet another ad-hoc parser, but this may be legitimized here by legacy considerations.  (I believe the CRLF handling is appropriate.) I also see the problems with staleness and verification.
I think requiring a mandatory expiration date in every security.txt could help a bit with the staleness issue.

I also believe this text need some good reread.  E.g., the following two sentences lead to obvious nonsense: »   This text file contains multiple directives with different values.
   The "directive" is the first part of a field all the way up to the
   colon ("Contact:") and follows the syntax defined for "field-name" in
   section 3.6.8 of [RFC5322].  «
Do the values really need to be different?  Isn’t the file containing fields, not just the directives (which demonstrates that “directive” is a bad name for a directive name)?

Grüße, Carsten