Should "Contact" be a URI or broken out into email and telephone? about security-txt HOT 6 CLOSED

Apologies for the late feedback on this -- but it seems misguided to allow values that don't adhere to an existing RFC. I understand the argument for ease of use, but I'd argue that ease of parsing against known RFCs should hold precedent in the specification itself. There are specs already, like humans.txt that are designed for 'ease of human use', so I'd vote for rigidity and technical cleanliness over trying to squeeze unstructured data into this directive.

from security-txt.

I think I can shed a bit of light into that decision - we did in fact toy with that very idea.

The main result of that conversation, however, was that people are free to use tel and mailto prefixes as they're valid URIs, but we wanted it to be easier for humans to read and write the files - and we thought that email addresses and phone numbers tend to read more naturally without the prefixes.

In writing a couple of parser implementations I determined it to not be too much extra effort to allow the prefixless phone numbers and email addresses, so it made it into the spec as a balance of "usability" and "not making parsing too difficult"

from security-txt.

Got it, I am adding some language clarifying this to the draft

from security-txt.

Good idea! :)

from security-txt.

Since security.txt is intended to be parsable by programs, the readability is not so important. Simplifying the grammar by just defining the value as an URI would be more homogeneous, and would allow other ways to contact people such as XMPP.

from security-txt.

Done: #81.

from security-txt.