diff --git a/draft-foudil-securitytxt.html b/draft-foudil-securitytxt.html
index 54c6057..5792539 100644
--- a/draft-foudil-securitytxt.html
+++ b/draft-foudil-securitytxt.html
@@ -9,32 +9,82 @@
 
   
 <style type="text/css">/*<![CDATA[*/
+@viewport {
+  zoom: 1.0;
+  width: extend-to-zoom;
+}
+@-ms-viewport {
+  width: extend-to-zoom;
+  zoom: 1.0;
+}
+
+@media screen and (min-width: 1024px) {
+  body>ul.toc, body>#rfc\.toc {
+    position: fixed;
+    bottom: 0;
+    right: 0;
+    right: calc(50vw - 550px);
+    width: 300px;
+    z-index: 1;
+  }
+  #rfc\.toc {
+    top: 55px;
+    overflow: auto;
+    overscroll-behavior: contain;
+  }
+  ul.toc, #rfc\.toc {
+    overflow: auto;
+    overscroll-behavior: contain;
+  }
+  body>ul.toc {
+    top: 140px;
+  }
+
+  body {
+    padding-right: 350px;
+  }
+}
 
 body {
-  font: 16px "Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
+  font: 16px "Helvetica Neue",Helvetica,Arial,sans-serif;
   color: #333;
   font-size-adjust: 0.5;
   line-height: 24px;
   margin: 75px auto;
-  max-width: 624px;
-  padding: 0 5px;
+  max-width: 724px;
 }
 
-.title, .filename, h1, h2, h3, h4, h5 {
-  font: 16px "Roboto Condensed","Helvetica Neue","Open Sans",Helvetica,Calibri,sans-serif;
+.title, .filename, h1, h2, h3, h4 {
+  font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
   font-size-adjust: 0.5;
-  font-weight: bold;
+  font-weight: 500;
   color: #333;
   line-height: 100%;
-  margin: 1.2em 0 0.3em;
+  margin: 0.8em 0 0.3em;
 }
-.title, #rfc\.title h1 { font-size: 32px; }
-h1, section h1, h2, section h2, section h3, nav h2 { font-size: 20px; }
-h3, section h4, h4, section h5 { font-size: 16px; }
+.title { font-size: 36px; }
+h1 { font-size: 36px; }
+h2 { font-size: 24px; }
+h3, h4 { font-size: 18px; }
 h1 a[href], h2 a[href], h3 a[href], h4 a[href] {
   color: #333;
 }
 
+ul.toc li {
+  list-style: none;
+  text-indent: -2.5em;
+  padding-left: 2.5em;
+  padding-bottom: 5px;
+  margin: 0;
+}
+ul.toc ul {
+  margin: 0;
+}
+/* xml2rfc nests ul directly inside ul which messes with the style badly */
+ul.toc, ul.toc>ul, ul.toc ul>ul {
+  margin: 0 0 0 1.5em;
+}
+
 table {
   margin-left: 0em;
   border-collapse: collapse;
@@ -61,30 +111,28 @@
 }
 
 
-table.header, table#rfc\.headerblock {
+table.header {
   width: 100%;
 }
-table.header td, table#rfc\.headerblock td {
+table.header td {
   border: none;
   background-color: transparent;
   color: black;
-  padding: 0;
 }
 .filename {
-  display: block;
   color: rgb(119, 119, 119);
-  font-size: 20px;
+  font-size: 23px;
   font-weight: normal;
+  height: auto;
   line-height: 100%;
-  margin: 10px 0 32px;
 }
 #rfc\.abstract+p, #rfc\.abstract p {
-  font-size: 20px;
-  line-height: 28px;
+  font-size: 18px;
+  line-height: 27px%;
 }
 
-samp, tt, code, pre, span.tt {
-  font: 13.5px Consolas, monospace;
+samp, tt, code, pre {
+  font: 11pt consolas, monospace;
   font-size-adjust: none;
 }
 pre {
@@ -94,15 +142,13 @@
   padding: 5px;
   margin: 5px;
 }
-.figure, caption {
+.figure {
   font-style: italic;
   margin: 0 1.5em;
-  text-align: left;
 }
 
 address {
-  margin: 16px 2px;
-  line-height: 20px;
+  margin: 10px 0 0;
 }
 .vcard {
   font-style: normal;
@@ -110,8 +156,8 @@
 .vcardline {
   display: block;
 }
-.vcardline .fn, address b {
-  font-weight: normal;
+.vcardline .fn {
+  font-weight: bold;
 }
 .vcardline .hidden {
   display: none;
@@ -165,61 +211,17 @@
   background-color: #eee;
 }
 
-p, ol, ul, li {
+ol, ul, li, p {
   padding: 0;
+  margin: 0.5em 0 0.5em 2em;
 }
-p {
-  margin: 0.5em 0;
-}
-ol, ul {
-  margin: 0.2em 0 0.2em 2em;
-}
-li {
-  margin: 0.2em 0;
+li, p {
+  margin-left: 0;
 }
 address {
   font-style: normal;
 }
 
-ul.toc ul {
-  margin: 0 0 0 2em;
-}
-ul.toc li {
-  list-style: none;
-  margin: 0;
-}
-
-@media screen and (min-width: 924px) {
-  body {
-    padding-right: 350px;
-  }
-  body>ul.toc, body>#rfc\.toc {
-    position: fixed;
-    bottom: 0;
-    right: 0;
-    right: calc(50vw - 500px);
-    width: 300px;
-    z-index: 1;
-    overflow: auto;
-    overscroll-behavior: contain;
-  }
-  body>#rfc\.toc {
-    top: 55px;
-  }
-  body>ul.toc {
-    top: 100px;
-  }
-
-  ul.toc {
-    margin: 0 0 0 4px;
-    font-size: 12px;
-    line-height: 20px;
-  }
-  ul.toc ul {
-    margin-left: 1.2em;
-  }
-}
-
 .github-fork-ribbon-wrapper {
   display: none;
 }
@@ -276,8 +278,7 @@
   .github-fork-ribbon-wrapper {
     position: fixed;
   }
-  /*]]>*/</style>
-  <meta name="viewport" content="initial-scale=1.0">
+/*]]>*/</style>
 
 
   <link href="#rfc.toc" rel="Contents">
@@ -333,12 +334,12 @@
 <link href="#rfc.authors" rel="Chapter">
 
 
-  <meta name="generator" content="xml2rfc version 2.22.3 - https://tools.ietf.org/tools/xml2rfc" />
+  <meta name="generator" content="xml2rfc version 2.16.0 - https://tools.ietf.org/tools/xml2rfc" />
   <link rel="schema.dct" href="http://purl.org/dc/terms/" />
 
   <meta name="dct.creator" content="Foudil, E. and Y. Shafranovich" />
   <meta name="dct.identifier" content="urn:ietf:id:draft-foudil-securitytxt-06" />
-  <meta name="dct.issued" scheme="ISO8601" content="2019-04-19" />
+  <meta name="dct.issued" scheme="ISO8601" content="2019-06-04" />
   <meta name="dct.abstract" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />
   <meta name="description" content="When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format (&#8220;security.txt&#8221;) to help organizations describe the process for security researchers to follow in order to report security vulnerabilities." />
 
@@ -362,12 +363,12 @@
 <td class="right">Y. Shafranovich</td>
 </tr>
 <tr>
-<td class="left">Expires: October 21, 2019</td>
+<td class="left">Expires: December 6, 2019</td>
 <td class="right">Nightwatch Cybersecurity</td>
 </tr>
 <tr>
 <td class="left"></td>
-<td class="right">April 19, 2019</td>
+<td class="right">June 04, 2019</td>
 </tr>
 
     	
@@ -383,7 +384,7 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on October 21, 2019.</p>
+<p>This Internet-Draft will expire on December 6, 2019.</p>
 <h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
 <p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
@@ -698,7 +699,7 @@ <h1 id="rfc.section.4.1">
 <a href="#rfc.section.4.1">4.1.</a> <a href="#weblocation" id="weblocation">Web-based services</a>
 </h1>
 <p id="rfc.section.4.1.p.1">Web-based services SHOULD place the security.txt file under the /.well-known/ path; e.g. https://example.com/.well-known/security.txt as per <a href="#RFC5785" class="xref">[RFC5785]</a>. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>) to the security.txt file under the /.well-known/ path or be used as a fallback if the &#8220;.well-known&#8221; path cannot be used.</p>
-<p id="rfc.section.4.1.p.2">If retrieval of a &#8220;security.txt&#8221; file results in a redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>), the implementors MUST NOT follow redirects that lead to another domain or subdomain but SHOULD follow redirects within the same domain name (but not different subdomain on the same domain).</p>
+<p id="rfc.section.4.1.p.2">If retrieval of a &#8220;security.txt&#8221; file from the top-level path results in a redirect (as per section 6.4 of <a href="#RFC7231" class="xref">[RFC7231]</a>), the implementors MUST NOT follow that redirect if it leads to another domain or subdomain but SHOULD follow that redirect within the same domain name (but not different subdomain on the same domain).</p>
 <p id="rfc.section.4.1.p.3">The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.</p>
 <h1 id="rfc.section.4.2">
 <a href="#rfc.section.4.2">4.2.</a> <a href="#filesystems" id="filesystems">Filesystems</a>
@@ -735,8 +736,8 @@ <h1 id="rfc.section.5">
 
 sign-footer      =  &lt;OpenPGP signature from section 7 of [RFC4880]&gt;
 
-unsigned         =  *line [canonical-field eol *line] [lang-field eol] *line
-unsigned         =/ *line [lang-field eol *line] [canonical-field eol] *line
+unsigned         =  *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line
+                    ; the order of elements is not important
 
 line             =  (field / comment) eol
 
@@ -755,7 +756,7 @@ <h1 id="rfc.section.5">
 
 ack-field        =  "Acknowledgments" fs SP uri
 
-canonical-field  =  "Canonical" fs SP uri
+can-field        =  "Canonical" fs SP uri
 
 contact-field    =  "Contact" fs SP uri
 
@@ -789,7 +790,7 @@ <h1 id="rfc.section.6.1">
 <p id="rfc.section.6.1.p.1">An attacker that has compromised a website is able to compromise the &#8220;security.txt&#8221; file as well or setup a redirect to their own site.  This can result in security reports not being received by the organization or sent to the attacker.</p>
 <p id="rfc.section.6.1.p.2">To protect against this, organizations SHOULD digitally sign their &#8220;security.txt&#8221; files (as per <a href="#signature" class="xref">Section 3.4</a>), use the canonical directive to sign the location of the file (as per <a href="#canonical" class="xref">Section 3.5.2</a>), and regularly monitor the file and the referenced resources to detect tampering.</p>
 <p id="rfc.section.6.1.p.3">Security researchers SHOULD check the &#8220;security.txt&#8221; file including verifying the digital signature and checking any available historical records before using the information contained in the file. If &#8220;security.txt&#8221; file looks suspicious or compromised, it SHOULD NOT be used.</p>
-<p id="rfc.section.6.1.p.4">To avoid redirect attacks, redirects for these files MUST NOT be followed if they lead to a different domain (as per <a href="#weblocation" class="xref">Section 4.1</a>).</p>
+<p id="rfc.section.6.1.p.4">To avoid redirect attacks, redirects for these files MUST NOT be followed when the file is placed in the top level path if they lead to a different domain (as per <a href="#weblocation" class="xref">Section 4.1</a>).</p>
 <h1 id="rfc.section.6.2">
 <a href="#rfc.section.6.2">6.2.</a> <a href="#incorrect-or-stale-information" id="incorrect-or-stale-information">Incorrect or Stale Information</a>
 </h1>
@@ -1150,7 +1151,11 @@ <h1 id="rfc.appendix.B.7">
 </h1>
 <p></p>
 
-<ul><li>Fixed ABNF grammar for non-chainable directives (#150)</li></ul>
+<ul>
+<li>Fixed ABNF grammar for non-chainable directives (#150)</li>
+<li>Clarified ABNF grammar (#152)</li>
+<li>Clarified redirect logic (#143)</li>
+</ul>
 <p id="rfc.section.B.7.p.2">Full list of changes can be viewed via the IETF document tracker: https://tools.ietf.org/html/draft-foudil-securitytxt</p>
 <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
 <div class="avoidbreak">
diff --git a/draft-foudil-securitytxt.md b/draft-foudil-securitytxt.md
index 2b3223d..881de9d 100644
--- a/draft-foudil-securitytxt.md
+++ b/draft-foudil-securitytxt.md
@@ -366,10 +366,10 @@ Web-based services SHOULD place the security.txt file under the /.well-known/ pa
 as per {{!RFC5785}}. A security.txt file located under the top-level path SHOULD either redirect (as per section 6.4 of {{!RFC7231}})
 to the security.txt file under the /.well-known/ path or be used as a fallback if the ".well-known" path cannot be used.
 
-If retrieval of a "security.txt" file results in a redirect (as per
-section 6.4 of {{!RFC7231}}), the implementors MUST NOT follow
-redirects that lead to another domain or subdomain
-but SHOULD follow redirects within the same domain name
+If retrieval of a "security.txt" file from the top-level path results in a redirect (as per
+section 6.4 of {{!RFC7231}}), the implementors MUST NOT follow that
+redirect if it leads to another domain or subdomain
+but SHOULD follow that redirect within the same domain name
 (but not different subdomain on the same domain).
 
 The guidance regarding redirects SHOULD NOT apply to the resource locations that appear within the file.
@@ -421,8 +421,8 @@ sign-header      =  <headers and line from section 7 of [RFC4880]>
 
 sign-footer      =  <OpenPGP signature from section 7 of [RFC4880]>
 
-unsigned         =  *line [canonical-field eol *line] [lang-field eol] *line
-unsigned         =/ *line [lang-field eol *line] [canonical-field eol] *line
+unsigned         =  *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line
+                    ; the order of elements is not important
 
 line             =  (field / comment) eol
 
@@ -441,7 +441,7 @@ comment          =  "#" *(WSP / VCHAR / %x80-FFFFF)
 
 ack-field        =  "Acknowledgments" fs SP uri
 
-canonical-field  =  "Canonical" fs SP uri
+can-field        =  "Canonical" fs SP uri
 
 contact-field    =  "Contact" fs SP uri
 
@@ -488,7 +488,8 @@ contained in the file. If "security.txt" file looks suspicious or compromised,
 it SHOULD NOT be used.
 
 To avoid redirect attacks, redirects for these files MUST NOT be followed
-if they lead to a different domain (as per {{weblocation}}).
+when the file is placed in the top level path if they lead to a different
+domain (as per {{weblocation}}).
 
 ## Incorrect or Stale Information
 
@@ -743,6 +744,8 @@ of DNS-stored encryption keys (#28 and #94)
 
 ## Since draft-foudil-securitytxt-06
 - Fixed ABNF grammar for non-chainable directives (#150)
+- Clarified ABNF grammar (#152)
+- Clarified redirect logic (#143)
 
 Full list of changes can be viewed via the IETF document tracker:
 https://tools.ietf.org/html/draft-foudil-securitytxt
diff --git a/draft-foudil-securitytxt.txt b/draft-foudil-securitytxt.txt
index 65c43ed..3b3ae4c 100644
--- a/draft-foudil-securitytxt.txt
+++ b/draft-foudil-securitytxt.txt
@@ -5,8 +5,8 @@
 Network Working Group                                          E. Foudil
 Internet-Draft
 Intended status: Informational                           Y. Shafranovich
-Expires: October 21, 2019                       Nightwatch Cybersecurity
-                                                          April 19, 2019
+Expires: December 6, 2019                       Nightwatch Cybersecurity
+                                                           June 04, 2019
 
 
                    A Method for Web Security Policies
@@ -36,7 +36,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on October 21, 2019.
+   This Internet-Draft will expire on December 6, 2019.
 
 Copyright Notice
 
@@ -53,9 +53,9 @@ Copyright Notice
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 1]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 1]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    the Trust Legal Provisions and are provided without warranty as
@@ -90,14 +90,14 @@ Table of Contents
    5.  File Format Description and ABNF Grammar  . . . . . . . . . .  11
    6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
      6.1.  Compromised Files and Redirects . . . . . . . . . . . . .  12
-     6.2.  Incorrect or Stale Information  . . . . . . . . . . . . .  12
+     6.2.  Incorrect or Stale Information  . . . . . . . . . . . . .  13
      6.3.  Intentionally Malformed Files, Resources and Reports  . .  13
      6.4.  No Implied Permission for Testing . . . . . . . . . . . .  13
      6.5.  Multi-user Environments . . . . . . . . . . . . . . . . .  13
      6.6.  Protecting Data in Transit  . . . . . . . . . . . . . . .  14
      6.7.  Spam and Spurious Reports . . . . . . . . . . . . . . . .  14
    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
-     7.1.  Well-Known URIs registry  . . . . . . . . . . . . . . . .  14
+     7.1.  Well-Known URIs registry  . . . . . . . . . . . . . . . .  15
      7.2.  Registry for security.txt Header Fields . . . . . . . . .  15
    8.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  16
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
@@ -109,9 +109,9 @@ Table of Contents
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 2]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 2]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
      B.2.  Since draft-foudil-securitytxt-01 . . . . . . . . . . . .  20
@@ -165,9 +165,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 3]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 3]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 1.2.  Terminology
@@ -221,9 +221,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 4]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 4]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    unlimited number of fields.  It is important to note that you MUST
@@ -277,9 +277,9 @@ https://[2001:db8:8:4::2]/.well-known/security.txt
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 5]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 5]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 3.3.  Separate Fields
@@ -333,9 +333,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 6]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 6]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 3.5.2.  Canonical
@@ -389,9 +389,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 7]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 7]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    When it comes to verifying the authenticity of the key, it is always
@@ -445,9 +445,9 @@ Encryption: dns:5d2d37ab76d47d36._openpgpkey.example.com?type=OPENPGPKEY
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 8]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 8]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    The order in which they appear MUST NOT be interpreted as an
@@ -501,9 +501,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019                [Page 9]
+Foudil & Shafranovich   Expires December 6, 2019                [Page 9]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 4.  Location of the security.txt file
@@ -517,11 +517,11 @@ Internet-Draft     A Method for Web Security Policies         April 2019
    security.txt file under the /.well-known/ path or be used as a
    fallback if the ".well-known" path cannot be used.
 
-   If retrieval of a "security.txt" file results in a redirect (as per
-   section 6.4 of [RFC7231]), the implementors MUST NOT follow redirects
-   that lead to another domain or subdomain but SHOULD follow redirects
-   within the same domain name (but not different subdomain on the same
-   domain).
+   If retrieval of a "security.txt" file from the top-level path results
+   in a redirect (as per section 6.4 of [RFC7231]), the implementors
+   MUST NOT follow that redirect if it leads to another domain or
+   subdomain but SHOULD follow that redirect within the same domain name
+   (but not different subdomain on the same domain).
 
    The guidance regarding redirects SHOULD NOT apply to the resource
    locations that appear within the file.
@@ -557,9 +557,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 10]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 10]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    In general, implementors SHOULD "be conservative in what you do, be
@@ -582,8 +582,8 @@ sign-header      =  <headers and line from section 7 of [RFC4880]>
 
 sign-footer      =  <OpenPGP signature from section 7 of [RFC4880]>
 
-unsigned         =  *line [canonical-field eol *line] [lang-field eol] *line
-unsigned         =/ *line [lang-field eol *line] [canonical-field eol] *line
+unsigned         =  *line [can-field eol] *line (contact-field eol) *line [lang-field eol] *line
+                    ; the order of elements is not important
 
 line             =  (field / comment) eol
 
@@ -602,7 +602,7 @@ comment          =  "#" *(WSP / VCHAR / %x80-FFFFF)
 
 ack-field        =  "Acknowledgments" fs SP uri
 
-canonical-field  =  "Canonical" fs SP uri
+can-field        =  "Canonical" fs SP uri
 
 contact-field    =  "Contact" fs SP uri
 
@@ -613,9 +613,9 @@ uri              =  <URI as per [RFC3986]>
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 11]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 11]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 encryption-field =  "Encryption" fs SP uri
@@ -659,21 +659,25 @@ unstructured     =  <imported from section 3.2.5 of [RFC5322]>
    used.
 
    To avoid redirect attacks, redirects for these files MUST NOT be
-   followed if they lead to a different domain (as per Section 4.1).
+   followed when the file is placed in the top level path if they lead
+   to a different domain (as per Section 4.1).
+
+
 
-6.2.  Incorrect or Stale Information
 
-   If information and resources referenced in a "security.txt" file are
-   incorrect or not kept up to date, this can result in security reports
 
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 12]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 12]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
+6.2.  Incorrect or Stale Information
+
+   If information and resources referenced in a "security.txt" file are
+   incorrect or not kept up to date, this can result in security reports
    not being received by the organization or sent to incorrect contacts,
    thus exposing possible security issues to third parties.
 
@@ -718,18 +722,17 @@ Internet-Draft     A Method for Web Security Policies         April 2019
    In multi-user / multi-tenant environments, it may possible for a user
    to take over the location of the "security.txt" file.  Organizations
    SHOULD reserve the "security.txt" namespace to ensure no third-party
-   can create a page with the "security.txt" AND "/.well-known/
-   security.txt" names.
-
 
 
 
-
-Foudil & Shafranovich   Expires October 21, 2019               [Page 13]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 13]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
+   can create a page with the "security.txt" AND "/.well-known/
+   security.txt" names.
+
 6.6.  Protecting Data in Transit
 
    To protect a "security.txt" file from being tampered in transit,
@@ -773,18 +776,20 @@ Internet-Draft     A Method for Web Security Policies         April 2019
    192.0.2.0 and 2001:db8:8:4::2 are used in this document following the
    uses indicated in [RFC6890].
 
-7.1.  Well-Known URIs registry
 
-   The "Well-Known URIs" registry should be updated with the following
-   additional values (using the template from [RFC5785]):
 
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 14]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 14]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
+
 
+7.1.  Well-Known URIs registry
+
+   The "Well-Known URIs" registry should be updated with the following
+   additional values (using the template from [RFC5785]):
 
    URI suffix: security.txt
 
@@ -832,14 +837,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-
-
-
-
-
-Foudil & Shafranovich   Expires October 21, 2019               [Page 15]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 15]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    Field Name: Acknowledgments
@@ -893,9 +893,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 16]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 16]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    The authors would also like to acknowledge the feedback provided by
@@ -949,9 +949,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 17]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 17]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
@@ -1005,9 +1005,9 @@ Internet-Draft     A Method for Web Security Policies         April 2019
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 18]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 18]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 9.2.  Informative References
@@ -1061,9 +1061,9 @@ Appendix A.  Note to Readers
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 19]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 19]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 Appendix B.  Document History
@@ -1117,9 +1117,9 @@ B.2.  Since draft-foudil-securitytxt-01
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 20]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 20]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
 B.3.  Since draft-foudil-securitytxt-02
@@ -1173,9 +1173,9 @@ B.5.  Since draft-foudil-securitytxt-04
 
 
 
-Foudil & Shafranovich   Expires October 21, 2019               [Page 21]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 21]
 
-Internet-Draft     A Method for Web Security Policies         April 2019
+Internet-Draft     A Method for Web Security Policies          June 2019
 
 
    o  Removed permission directive (#30)
@@ -1205,6 +1205,10 @@ B.7.  Since draft-foudil-securitytxt-06
 
    o  Fixed ABNF grammar for non-chainable directives (#150)
 
+   o  Clarified ABNF grammar (#152)
+
+   o  Clarified redirect logic (#143)
+
    Full list of changes can be viewed via the IETF document tracker:
    https://tools.ietf.org/html/draft-foudil-securitytxt
 
@@ -1225,8 +1229,4 @@ Authors' Addresses
 
 
 
-
-
-
-
-Foudil & Shafranovich   Expires October 21, 2019               [Page 22]
+Foudil & Shafranovich   Expires December 6, 2019               [Page 22]