Skip to content

Commit

Permalink
Cleanup
Browse files Browse the repository at this point in the history
  • Loading branch information
@ralfhandl
ralfhandl committed Jul 21, 2023
1 parent b65b4b7 commit 86b8ed7
Show file tree
Hide file tree
Showing 13 changed files with 2 additions and 106 deletions.
5 changes: 0 additions & 5 deletions docs/odata-csdl-json/odata-csdl-json.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -320,11 +320,6 @@ <h6 id="rfc3552">[RFC3552]</h6>
<h1 id="appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</h1>
<!-- Optional section -->

<p><code>(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.</code></p>
<p><code>While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.</code></p>
<p><code>In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.</code></p>
<p><code>We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.</code></p>
<p><code>Remove this note before submitting for publication.)</code></p>
<hr />
<h1 id="appendix-c-acknowledgments">Appendix C. Acknowledgments</h1>
<!-- Required section -->
Expand Down
10 changes: 0 additions & 10 deletions docs/odata-csdl-json/odata-csdl-json.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -342,16 +342,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
5 changes: 0 additions & 5 deletions docs/odata-csdl-xml/odata-csdl-xml.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -320,11 +320,6 @@ <h6 id="rfc3552">[RFC3552]</h6>
<h1 id="appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</h1>
<!-- Optional section -->

<p><code>(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.</code></p>
<p><code>While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.</code></p>
<p><code>In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.</code></p>
<p><code>We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.</code></p>
<p><code>Remove this note before submitting for publication.)</code></p>
<hr />
<h1 id="appendix-c-acknowledgments">Appendix C. Acknowledgments</h1>
<!-- Required section -->
Expand Down
10 changes: 0 additions & 10 deletions docs/odata-csdl-xml/odata-csdl-xml.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -342,16 +342,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
5 changes: 0 additions & 5 deletions docs/odata-protocol/odata-protocol.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -320,11 +320,6 @@ <h6 id="rfc3552">[RFC3552]</h6>
<h1 id="appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</h1>
<!-- Optional section -->

<p><code>(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.</code></p>
<p><code>While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.</code></p>
<p><code>In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.</code></p>
<p><code>We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.</code></p>
<p><code>Remove this note before submitting for publication.)</code></p>
<hr />
<h1 id="appendix-c-acknowledgments">Appendix C. Acknowledgments</h1>
<!-- Required section -->
Expand Down
10 changes: 0 additions & 10 deletions docs/odata-protocol/odata-protocol.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -344,16 +344,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
5 changes: 0 additions & 5 deletions docs/odata-url-conventions/odata-url-conventions.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -320,11 +320,6 @@ <h6 id="rfc3552">[RFC3552]</h6>
<h1 id="appendix-b-safety-security-and-privacy-considerations">Appendix B. Safety, Security and Privacy Considerations</h1>
<!-- Optional section -->

<p><code>(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.</code></p>
<p><code>While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.</code></p>
<p><code>In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.</code></p>
<p><code>We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.</code></p>
<p><code>Remove this note before submitting for publication.)</code></p>
<hr />
<h1 id="appendix-c-acknowledgments">Appendix C. Acknowledgments</h1>
<!-- Required section -->
Expand Down
10 changes: 0 additions & 10 deletions docs/odata-url-conventions/odata-url-conventions.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -344,16 +344,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
8 changes: 2 additions & 6 deletions lib/number.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -119,9 +119,7 @@ class Number {
for (var m, regex = /\]\(#(.*?)\)/g; (m = regex.exec(line)); )
if (!this.refs[m[1]])
this.errors.push(
`Undefined link #${m[1]} in file ${
this.dir + "/" + file
}, line ${lineno}`
`Undefined link #${m[1]} in file ${this.dir}/${file}, line ${lineno}`
);
m = line.match(/ ##([A-Za-z]+)(_([A-Za-z]+))?/);
if (m && line[m.index + m[0].length] !== "]") {
Expand All @@ -143,9 +141,7 @@ class Number {
if (r) return `${r}](#${p})`;
else {
this.errors.push(
`Undefined link ##${p} in file ${
this.dir + "/" + file
}, line ${lineno}`
`Undefined link ##${p} in file ${this.dir}/${file}, line ${lineno}`
);
return `~~${p}~~]`;
}
Expand Down
10 changes: 0 additions & 10 deletions odata-csdl-json/odata-csdl-json-v4.02-csd01.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -345,16 +345,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
10 changes: 0 additions & 10 deletions odata-csdl-xml/odata-csdl-xml-v4.02-csd01.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -345,16 +345,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
10 changes: 0 additions & 10 deletions odata-protocol/odata-v4.02-csd01-part1-protocol.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -347,16 +347,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down
10 changes: 0 additions & 10 deletions odata-url-conventions/odata-v4.02-csd01-part2-url-conventions.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -347,16 +347,6 @@ Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Conside

<!-- Optional section -->

`(Note: OASIS strongly recommends that Technical Committees consider issues that might affect safety, security, privacy, and/or data protection in implementations of their specification and document them for implementers and adopters. For some purposes, you may find it required, e.g. if you apply for IANA registration.`

`While it may not be immediately obvious how your specification might make systems vulnerable to attack, most specifications, because they involve communications between systems, message formats, or system settings, open potential channels for exploit. For example, IETF [[RFC3552](#rfc3552)] lists “eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle” as well as potential denial of service attacks as threats that must be considered and, if appropriate, addressed in IETF RFCs.`

`In addition to considering and describing foreseeable risks, this section should include guidance on how implementers and adopters can protect against these risks.`

`We encourage editors and TC members concerned with this subject to read _Guidelines for Writing RFC Text on Security Considerations_, IETF [[RFC3552](#rfc3552)], for more information.`

`Remove this note before submitting for publication.)`

-------

# Appendix C. Acknowledgments
Expand Down

0 comments on commit 86b8ed7

Please sign in to comment.