On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann <cabo@xxxxxxx> wrote:
> On Dec 28, 2019, at 18:58, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
>
> 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?)
>
The concern was that once the draft is published, defining additional
required fields via the registry may lead to compatibility issues
between the people doing the publishing and the researchers parsing
the files. However, since the next sentence says that people
reading/parsing the file should ignore anything not supported, perhaps
this is not needed?
"To encourage extensibility and interoperability, implementers MUST
ignore any fields they do not explicitly support."
> .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.
>
That is a great idea, I am going to add an "Expires" field to the
draft and some language in the security section around that as well.
> 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)?
>
Will address this by calling them fields, names and values instead of directives
On Mon, Dec 30, 2019 at 10:10 PM Nightwatch Cybersecurity Research
<research@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sun, Dec 29, 2019 at 3:07 AM Carsten Bormann <cabo@xxxxxxx> wrote:
> > On Dec 28, 2019, at 18:58, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
> >
> > 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?)
> >
>
> The concern was that once the draft is published, defining additional
> required fields via the registry may lead to compatibility issues
> between the people doing the publishing and the researchers parsing
> the files. However, since the next sentence says that people
> reading/parsing the file should ignore anything not supported, perhaps
> this is not needed?
>
> "To encourage extensibility and interoperability, implementers MUST
> ignore any fields they do not explicitly support."
>
> > .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.
> >
>
> That is a great idea, I am going to add an "Expires" field to the
> draft and some language in the security section around that as well.
>
> > 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)?
> >
>
> Will address this by calling them fields, names and values instead of directives
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
