Start working on draft version 03. - #81
Conversation
updated issues shield/link
chore(text): fix grammar
chore(text): fix grammar
Fix Typo and Shield Link
Fix Typo and Shield Link
Conversion to markdown and adding IETF drafting tools
Removing non-markdown draft version
Adding IANA registration for .well-known and removing date
Adding IANA registry for extensibility to address issue #34
There was a problem hiding this comment.
@EdOverflow ABNF's should be <pre>'d I believe if you wanted to get that into this draft
| As stated in {{encryption}} and {{signature}}, both encryption keys | ||
| and external signature files SHOULD be loaded over HTTPS. | ||
|
|
||
| Web services MUST reserve the security.txt namespace to ensure no third-party can create a page with the "security.txt" name. |
There was a problem hiding this comment.
Can we explain what this means? "Web services" has multiple meanings. Are we talking about a multi user host like Wordpress.com or Blogger?
There was a problem hiding this comment.
@nightwatchcyber, is there an RFC that we could reference here in order to define https://en.wikipedia.org/wiki/Web_service?
There was a problem hiding this comment.
Can we first figure out what we mean by "web service"? In my mind I was thinking of a domain name or IP addresses providing connections via HTTP protocol on port 80, but not necessarily machine to machine only. What is your thought?
| While URIs already include the ability to have both email address and phone | ||
| numbers via "mailto" and "tel" prefixes, allowing this information to be listed | ||
| without a prefix is intended for ease of use and readability. | ||
| The value MUST follow the general syntax described in {{!RFC3986}}. This means that "mailto" and "tel" URI schemes are required. |
There was a problem hiding this comment.
I wonder if the wording should be "This means that "mailto" and "tel" URI schemes MUST be used when specifying email addresses and telephone numbers"
| ## Web-based services | ||
|
|
||
| Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt. | ||
| Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt. A security.txt file located under the top-level path SHOULD either redirect to the security.txt file under the /.well-known/ path or be used as a fall back. |
There was a problem hiding this comment.
Do we want to explain what "fall back" means? Same for line 69 above.
Perhaps "A security.txt file located under the top-level path SHOULD redirect to the security.txt file under the /.well-known/. If it is not possible to place the security.txt file in the /.well-known/ path or setup a redirect, web-based services MAY place the file in the top-level path as a fall back option*"
|
|
||
| The expected file format of the security.txt file is plain text as defined | ||
| in section 4.1.3 of {{!RFC2046}} and encoded in UTF-8. | ||
| in section 4.1.3 of {{!RFC2046}} and follow {{!RFC5198}}. |
There was a problem hiding this comment.
I would recommend to follow the convention of RFC 7252:
https://tools.ietf.org/html/rfc7252#section-3.2
and would suggest the following wording: "and is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]"
| @@ -257,11 +260,12 @@ implementors MUST ignore any fields they do not explicitly support. | |||
| # File Format Description | |||
|
|
|||
| The expected file format of the security.txt file is plain text as defined | |||
There was a problem hiding this comment.
Wondering also if we want to change "plain text" to read "plain text (MIME type "text/plain")"
|
|
||
| A security.txt file only applies to the domain, subdomain, IPv4 or IPv6 address | ||
| it is located in. | ||
| A security.txt file only applies to the domain in the URI used to retrieve it, not to any of its subdomains or parent domains. |
There was a problem hiding this comment.
What about IP addresses? Only for that IP and not anything in the same subnet, above or below? Or is that self evident?
What about file systems?
| /.well-known/ path ("/.well-known/security.txt") {{!RFC5785}} for web | ||
| properties. For file systems and version control repositories a .security.txt | ||
| file should be placed in the root directory. This text file contains 4 directives | ||
| properties. A security.txt file located under the website's top-level directory can either redirect to the security.txt file located under the /.well-known/ path or be used as a fall back. For web-based services, the instructions must be accessible via the Hypertext Transfer Protocol {{!RFC1945}} as a resource of Internet Media Type "text/plain;charset=utf8" {{!RFC1590}}. For file systems and version control repositories a .security.txt file SHOULD be placed in the root directory. This text file contains 4 directives |
There was a problem hiding this comment.
We may want a new line before "This text file contains..."
Also "contains 4 directives" isn't really true anymore, maybe reword this as "contains multiple directives"?
| properties. For file systems and version control repositories a .security.txt | ||
| file should be placed in the root directory. This text file contains 4 directives | ||
| properties. A security.txt file located under the website's top-level directory can either redirect to the security.txt file located under the /.well-known/ path or be used as a fall back. For web-based services, the instructions must be accessible via the Hypertext Transfer Protocol {{!RFC1945}} as a resource of Internet Media Type "text/plain;charset=utf8" {{!RFC1590}}. For file systems and version control repositories a .security.txt file SHOULD be placed in the root directory. This text file contains 4 directives | ||
| with different values. The "directive" is the first part of a field all the way up |
There was a problem hiding this comment.
Do we want to reference how headers are parsed in other protocols?
|
|
||
| A security.txt file only applies to the domain, subdomain, IPv4 or IPv6 address | ||
| it is located in. | ||
| A security.txt file only applies to the domain in the URI used to retrieve it, not to any of its subdomains or parent domains. |
There was a problem hiding this comment.
I also wonder if "only applies" may need to read strong as "MUST only apply"?
| /.well-known/ path ("/.well-known/security.txt") {{!RFC5785}} for web | ||
| properties. For file systems and version control repositories a .security.txt | ||
| file should be placed in the root directory. This text file contains 4 directives | ||
| properties. A security.txt file located under the website's top-level directory can either redirect to the security.txt file located under the /.well-known/ path or be used as a fall back. For web-based services, the instructions must be accessible via the Hypertext Transfer Protocol {{!RFC1945}} as a resource of Internet Media Type "text/plain;charset=utf8" {{!RFC1590}}. For file systems and version control repositories a .security.txt file SHOULD be placed in the root directory. This text file contains 4 directives |
There was a problem hiding this comment.
The reference to RFC1590 should probably be changed to point to section 4.1.3 of RFC2046 as per the rest of the draft, or maybe the media type registration.
For the charset, we may want to say something like "should be served with the default charset parameter set to "utf-8"
* Languages updates for the draft text * Fix comment * Fix more wording * Fix for Ed
|
@austinheap, the ABNF grammar is already |
7 participants
https://github.com/securitytxt/security-txt/milestone/4