Standardises referencing label format

“RFCxxx Section x.x” rather than “Section x.x of RFCxxx”.

contents/codes/100.md

@@ -20,7 +20,7 @@ If the request did not contain an Expect header field containing the
 
 ---
 
-* <span id="ref-1"><sup>1</sup> As described in [RFC7231 Section 5.1.1][2]</span>
+* <span id="ref-1"><sup>1</sup> Expect [RFC7231 Section 5.1.1][2]</span>
 * Source: [RFC7231 Section 6.1.1][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.2.1>

contents/codes/101.md

@@ -21,7 +21,7 @@ protocol might be advantageous when delivering resources that use such features.
 
 ---
 
-* <span id="ref-1"><sup>1</sup> As described in [Section 6.7 of RFC7230][2]</span>
+* <span id="ref-1"><sup>1</sup> Upgrade [RFC7230 Section 6.7][2]</span>
 * Source: [RFC7231 Section 6.2.2][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.2.2>

contents/codes/200.md

@@ -31,7 +31,7 @@ method definition or explicit cache controls<sup>[1](#ref-1)</sup>.
 ---
 
 * <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
-[Section 4.2.2 of RFC7234][2]</span>
+[RFC7234 Section 4.2.2][2]</span>
 * Source: [RFC7231 Section 6.3.1][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.3.1>

contents/codes/203.md

@@ -25,10 +25,10 @@ method definition or explicit cache controls<sup>[3](#ref-3)</sup>.
 ---
 
 * <span id="ref-1"><sup>1</sup> Transformations
-[Section 5.7.2 of RFC7230][2]</span>
-* <span id="ref-2"><sup>2</sup> Warning [Section 5.5 of RFC7234][3]</span>
+[RFC7230 Section 5.7.2][2]</span>
+* <span id="ref-2"><sup>2</sup> Warning [RFC7234 Section 5.5][3]</span>
 * <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
-[Section 4.2.2 of RFC7234][4]</span>
+[RFC7234 Section 4.2.2][4]</span>
 * Source: [RFC7231 Section 6.3.4][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.3.4>

contents/codes/204.md

@@ -39,7 +39,7 @@ method definition or explicit cache controls<sup>[1](#ref-1)</sup>.
 ---
 
 * <span id="ref-1"><sup>1</sup> Calculating Heuristic Freshness
-[Section 4.2.2 of RFC7234][2]</span>
+[RFC7234 Section 4.2.2][2]</span>
 * Source: [RFC7231 Section 6.3.5][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.3.5>

contents/codes/206.md

@@ -108,7 +108,7 @@ explicit cache controls<sup>[3](#ref-3)</sup>.
 * <span id="ref-2"><sup>2</sup> Internet Media Type multipart/byteranges
 [RFC7233 Appendix A][3]</span>
 * <span id="ref-3"><sup>3</sup> Calculating Heuristic Freshness
-[Section 4.2.2 of RFC7234][4]</span>
+[RFC7234 Section 4.2.2][4]</span>
 * Source: [RFC7233 Section 4.1][1]
 
 [1]: <http://tools.ietf.org/html/rfc7233#section-4.1>

contents/codes/207.md

@@ -31,12 +31,12 @@ of the message execution for the identified resource as a
 whole<sup>[1](#ref-1)</sup>. Some method definitions provide information
 about specific status codes clients should be prepared to see in a response.
 However, clients MUST be able to handle other status codes, using the generic
-rules defined in [Section 10 of RFC2616][3].
+rules defined in [RFC2616 Section 10][3].
 
 2\. For PROPFIND and PROPPATCH, the format has been extended using the 'propstat'
 element instead of 'status', providing information about individual properties
 of a resource.  This format is specific to PROPFIND and PROPPATCH, and is
-described in detail in [RFC4918 Sections 9.1][4] and [RFC4918 9.2][5].
+described in detail in [RFC4918 Section 9.1][4] and [RFC4918 Section 9.2][5].
 
 ---
 

contents/codes/208.md

@@ -14,7 +14,7 @@ descendants are included.
 
 Note that the 208 status will only occur for "Depth: infinity" requests, and
 that it is of particular importance when the multiple collection bindings cause
-a bind loop as discussed in [RFC5842][2].
+a bind loop<sup>[1](#ref-1)</sup>.
 
 A client can request the DAV:resource-id property in a PROPFIND request to
 guarantee that they can accurately reconstruct the binding structure of a
@@ -23,7 +23,7 @@ collection with multiple bindings to a single resource.
 For backward compatibility with clients not aware of the 208 status code
 appearing in multistatus response bodies, it SHOULD NOT be used unless the
 client has signaled support for this specification using the "DAV" request
-header<sup>[1](#ref-1)</sup>. Instead, a [508 Loop Detected](/508) status should
+header<sup>[2](#ref-2)</sup>. Instead, a [508 Loop Detected](/508) status should
 be returned when a binding loop is discovered. This allows the server to return
 the 508 as the top-level return status, if it discovers it before it started the
 response, or in the middle of a multistatus, if it discovers it in the middle of
@@ -31,8 +31,10 @@ streaming out a multistatus response.
 
 ---
 
-* <span id="ref-1"><sup>1</sup> 'DAV' Request Header
-[RFC5842Section 8.2][3]</span>
+* <span id="ref-1"><sup>1</sup> URI Mappings Created by a New Binding
+[RFC5842 Section 2.2][2]</span>
+* <span id="ref-2"><sup>2</sup> 'DAV' Request Header
+[RFC5842 Section 8.2][3]</span>
 * Source: [RFC5842 Section 7.1][1]
 
 [1]: <http://tools.ietf.org/html/rfc5842#section-7.1>

contents/codes/300.md

@@ -46,7 +46,7 @@ though deployment is a chicken-and-egg problem.
 * <span id="ref-1"><sup>1</sup> Content Negotiation
 [RFC7231 Section 3.4][2]</span>
 * <span id="ref-2"><sup>2</sup> Calculating Heuristic Freshness
-[Section 4.2.2 of RFC7234][3]</span>
+[RFC7234 Section 4.2.2][3]</span>
 * <span id="ref-3"><sup>3</sup> Web Linking [RFC5988][4]</span>
 * Source: [RFC7231 Section 6.4.1][1]
 

contents/codes/426.md

@@ -26,7 +26,7 @@ This service requires use of the HTTP/3.0 protocol.
 
 ---
 
-* <span id="ref-1"><sup>1</sup> Upgrade [Section 6.7 of RFC7230][2]</span>
+* <span id="ref-1"><sup>1</sup> Upgrade [RFC7230 Section 6.7][2]</span>
 * Source: [RFC7231 Section 6.5.15][1]
 
 [1]: <http://tools.ietf.org/html/rfc7231#section-6.5.15>