idnits 2.17.1 draft-young-md-query-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 16, 2020) is 1561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7235 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational January 16, 2020 5 Expires: July 19, 2020 7 Metadata Query Protocol 8 draft-young-md-query-12 10 Abstract 12 This document defines a simple protocol for retrieving metadata about 13 named entities, or named collections of entities. The goal of the 14 protocol is to profile various aspects of HTTP to allow requesters to 15 rely on certain, rigorously defined, behaviour. 17 This document is a product of the Research and Education Federations 18 (REFEDS) Working Group process. 20 Editorial Note (To be removed by RFC Editor before publication) 22 Discussion of this draft takes place on the MDX mailing list 23 (mdx@lists.iay.org.uk), which is accessed from [MDX.list]. 25 XML versions, latest edits and the issues list for this document are 26 available from [md-query]. 28 The changes in this draft are summarized in Appendix A.13. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 19, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Protocol Transport . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Transport Protocol . . . . . . . . . . . . . . . . . . . 4 66 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.4. Request Headers . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Response Headers . . . . . . . . . . . . . . . . . . . . 5 70 2.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 5 71 2.7. Base URL . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.8. Content Negotiation . . . . . . . . . . . . . . . . . . . 6 73 3. Metadata Query Protocol . . . . . . . . . . . . . . . . . . . 6 74 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.2.1. Request by Identifier . . . . . . . . . . . . . . . . 7 77 3.2.2. Request All Entities . . . . . . . . . . . . . . . . 8 78 3.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 79 3.2.4. Example Request and Response . . . . . . . . . . . . 8 80 4. Efficient Retrieval and Caching . . . . . . . . . . . . . . . 9 81 4.1. Conditional Retrieval . . . . . . . . . . . . . . . . . . 9 82 4.2. Content Caching . . . . . . . . . . . . . . . . . . . . . 9 83 4.3. Content Compression . . . . . . . . . . . . . . . . . . . 9 84 5. Protocol Extension Points . . . . . . . . . . . . . . . . . . 10 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 6.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 87 6.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 88 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 93 9.2. Informative References . . . . . . . . . . . . . . . . . 12 94 Appendix A. Change Log (to be removed by RFC Editor before 95 publication) . . . . . . . . . . . . . . . . . . . . 13 96 A.1. Since draft-lajoie-md-query-01 . . . . . . . . . . . . . 13 97 A.2. Since draft-young-md-query-00 . . . . . . . . . . . . . . 13 98 A.3. Since draft-young-md-query-01 . . . . . . . . . . . . . . 14 99 A.4. Since draft-young-md-query-02 . . . . . . . . . . . . . . 14 100 A.5. Since draft-young-md-query-03 . . . . . . . . . . . . . . 14 101 A.6. Since draft-young-md-query-04 . . . . . . . . . . . . . . 14 102 A.7. Since draft-young-md-query-05 . . . . . . . . . . . . . . 15 103 A.8. Since draft-young-md-query-06 . . . . . . . . . . . . . . 15 104 A.9. Since draft-young-md-query-07 . . . . . . . . . . . . . . 15 105 A.10. Since draft-young-md-query-08 . . . . . . . . . . . . . . 15 106 A.11. Since draft-young-md-query-09 . . . . . . . . . . . . . . 15 107 A.12. Since draft-young-md-query-10 . . . . . . . . . . . . . . 15 108 A.13. Since draft-young-md-query-11 . . . . . . . . . . . . . . 15 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 111 1. Introduction 113 Many clients of web-based services are capable of consuming 114 descriptive metadata about a service in order to customize or obtain 115 information about the client's connection parameters. While the form 116 of the metadata (e.g., JSON, XML) and content varies between services 117 this document specifies a set of semantics for HTTP ([RFC7230] et 118 seq.) that allow clients to rely on certain behavior. The defined 119 behavior is meant to make it easy for clients to perform queries, to 120 be efficient for both requesters and responders, and to allow the 121 responder to scale in various ways. 123 The Research and Education Federations group ([REFEDS]) is the voice 124 that articulates the mutual needs of research and education identity 125 federations worldwide. It aims to represent the requirements of 126 research and education in the ever-growing space of access and 127 identity management. 129 From time to time REFEDS will wish to publish a document in the 130 Internet RFC series. Such documents will be published as part of the 131 RFC Independent Submission Stream [RFC4844]; however the REFEDS 132 working group sign-off process will have been followed for these 133 documents, as described in the REFEDS Participant's Agreement 134 [REFEDS.agreement]. 136 This document is a product of the REFEDS Working Group process. 138 1.1. Notation and Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 This document makes use of the Augmented BNF metalanguage defined in 147 [STD68]. 149 1.2. Terminology 151 entity: A single logical construct for which metadata may be 152 asserted. Generally this is a network accessible service. 154 metadata: A machine readable description of certain entity 155 characteristics. Generally metadata provides information such as 156 end point references, service contact information, etc. 158 2. Protocol Transport 160 The metadata query protocol seeks to fully employ the features of the 161 HTTP protocol. Additionally this specification makes mandatory some 162 optional HTTP features. 164 2.1. Transport Protocol 166 The metadata query protocol makes use of the HTTP protocol 167 ([RFC7230]) to transmit requests and responses. The underlying HTTP 168 connection MAY make use of any appropriate transport protocol. In 169 particular, the HTTP connection MAY make use of either TCP or TLS at 170 the transport layer. See the Security Considerations section for 171 guidance in choosing an appropriate transport protocol. 173 2.2. HTTP Version 175 Requests from clients MUST NOT use an HTTP version prior to version 176 1.1. Responders MUST reply to such requests using status code 505, 177 "HTTP Version Not Supported". 179 Protocol responders MUST support requests using HTTP version 1.1, and 180 MAY support later versions. 182 2.3. HTTP Method 184 All metadata query requests MUST use the GET method. 186 2.4. Request Headers 188 All metadata query requests MUST include the following HTTP headers: 190 Accept - this header MUST contain the content-type identifying the 191 type, or form, of metadata to be retrieved. See section 5.3.2 of 192 [RFC7231]. 194 All metadata query requests SHOULD include the following HTTP 195 headers: 197 Accept-Charset, see section 5.3.3 of [RFC7231] 199 Accept-Encoding, see section 5.3.4 of [RFC7231] 201 A metadata request to the same URL, after an initial request, MUST 202 include the following header: 204 If-None-Match, see section 3.2 of [RFC7232]. 206 2.5. Response Headers 208 All successful metadata query responses (even those that return no 209 results) MUST include the following headers: 211 Content-Encoding - required if, and only if, content is 212 compressed. See section 3.1.2.2 of [RFC7231]. 214 Content-Type, see section 3.1.1.5 of [RFC7231]. 216 ETag, see section 2.3 of [RFC7232]. 218 All metadata retrieval responses SHOULD include the following 219 headers: 221 Cache-Control, see section 5.2 of [RFC7234]. 223 Content-Length, see section 3.3.2 of [RFC7230] 225 Last-Modified, see section 2.2 of [RFC7232]. 227 2.6. Status Codes 229 This protocol uses the following HTTP status codes: 231 200 "OK" - standard response code when returning requested 232 metadata 234 304 "Not Modified" - response code indicating requested metadata 235 has not been updated since the last request 236 400 "Bad Request" - response code indicating that the requester's 237 request was malformed in some fashion 239 401 "Unauthorized" - response code indicating the request must be 240 authenticated before requesting metadata 242 404 "Not Found" - indicates that the requested metadata could not 243 be found; this MUST NOT be used in order to indicate a general 244 service error. 246 405 "Method Not Allowed" - response code indicating that a non-GET 247 method was used 249 406 "Not Acceptable" - response code indicating that metadata is 250 not available in the request content-type 252 505 "HTTP Version Not Supported" - response code indicating that 253 HTTP/1.1 was not used 255 2.7. Base URL 257 Requests defined in this document are performed by issuing an HTTP 258 GET request to a particular URL ([STD66]). The final component of 259 the path to which requests are issued is defined by the requests 260 specified within this document. A base URL precedes such paths. 261 Such a base URL: 263 o MUST contain the scheme and authority components. 265 o MUST contain a path component ending with a slash ('/') character. 267 o MUST NOT include a query component. 269 o MUST NOT include a fragment identifier component. 271 2.8. Content Negotiation 273 As there may be many representations for a given piece of metadata, 274 agent-driven content negotiation is used to ensure the proper 275 representation is delivered to the requester. In addition to the 276 required usage of the Accept header a responder SHOULD also support 277 the use of the Accept-Charset header. 279 3. Metadata Query Protocol 281 The metadata query protocol retrieves metadata either for all 282 entities known to the responder or for a named collection based on a 283 single "tag" or "keyword" identifier. A request returns information 284 for none, one, or a collection of entities. 286 3.1. Identifiers 288 The query protocol uses identifiers to "tag" metadata for single- and 289 multi-entity metadata collections. The assignment of such 290 identifiers to a particular metadata document is the responsibility 291 of the query responder. If a metadata collection already contains a 292 well known identifier it is RECOMMENDED that such a natural 293 identifier is used when possible. Any given metadata collection MAY 294 have more than one identifier associated with it. 296 An identifier used in the query protocol is a non-empty sequence of 297 arbitrary 8-bit characters: 299 id = 1*idchar 300 idchar = %x00-ff ; any encodable character 302 3.2. Protocol 304 3.2.1. Request by Identifier 306 A metadata query request for all entities tagged with a particular 307 identifier is performed by issuing an HTTP GET request to a URL 308 constructed as the concatenation of the following components: 310 o The responder's base URL. 312 o The string "entities/". 314 o A single identifier, percent-encoded appropriately for use as a 315 URL path segment (see sections 2.1 and 3.3 of [STD66]). 317 For example, with a base URL of "http://example.org/mdq/", a query 318 for the identifier "foo" would be performed by an HTTP GET request to 319 the following URL: 321 http://example.org/mdq/entities/foo 323 Correct encoding of the identifier as a URL path segment is critical 324 for interoperability. In particular: 326 The character '/' MUST be percent-encoded. 328 The space character MUST be encoded as '%20' and MUST NOT be 329 encoded as '+' as would be required in a query parameter. 331 For example, with a base URL of "http://example.org/mdq/", a query 332 for the identifier ""blue/green+light blue"" would be performed by an 333 HTTP GET request to the following URL: 335 http://example.org/mdq/entities/blue%2Fgreen+light%20blue 337 3.2.2. Request All Entities 339 A metadata query request for all entities known to the responder is 340 performed by issuing an HTTP GET request to a URL constructed as the 341 concatenation of the following components: 343 o The responder's base URL. 345 o The string "entities". 347 For example, with a base URL of "http://example.org/mdq/", a query 348 for all entities would be performed by an HTTP GET request to the 349 following URL: 351 http://example.org/mdq/entities 353 3.2.3. Response 355 The response to a metadata query request MUST be a document that 356 provides metadata for the given request in the format described by 357 the request's Accept header. 359 The responder is responsible for ensuring that the metadata returned 360 is valid. If the responder can not create a valid document it MUST 361 respond with a 406 status code. An example of such an error would be 362 the case where the result of the query is metadata for multiple 363 entities but the request content type does not support returning 364 multiple results in a single document. 366 3.2.4. Example Request and Response 368 The following example demonstrates a metadata query request using a 369 base URL of "http://metadata.example.org/service/" and the identifier 370 "http://example.org/idp". 372 GET /service/entities/http:%2F%2Fexample.org%2Fidp HTTP/1.1 373 Host: metadata.example.org 374 Accept: application/samlmetadata+xml 376 Example Metadata Query Request 378 HTTP/1.x 200 OK 379 Content-Type: application/samlmetadata+xml 380 ETag: "abcdefg" 381 Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT 382 Content-Length: 1234 384 385 387 .... 389 Example Metadata Query Response 391 4. Efficient Retrieval and Caching 393 4.1. Conditional Retrieval 395 Upon a successful response the responder MUST return an ETag header 396 and MAY return a Last-Modified header as well. Requesters SHOULD use 397 either or both, with the ETag being preferred, in any subsequent 398 requests for the same resource. 400 In the event that a resource has not changed since the previous 401 request, the responder SHOULD send a 304 (Not Modified) status code 402 as a response. 404 4.2. Content Caching 406 Responders SHOULD include cache control information with successful 407 (200 status code) responses, assuming the responder knows when 408 retrieved metadata is meant to expire. The responder SHOULD also 409 include cache control information with 404 Not Found responses. This 410 allows the requester to create and maintain a negative-response 411 cache. When cache controls are used only the 'max-age' directive 412 SHOULD be used. 414 4.3. Content Compression 416 As should be apparent from the required request and response headers 417 this protocol encourages the use of content compression. This is in 418 recognition that some metadata documents can be quite large or 419 fetched with relatively high frequency. 421 Requesters SHOULD support, and advertise support for, gzip 422 compression unless such usage would put exceptional demands on 423 constrained environments. Responders MUST support gzip compression. 424 Requesters and responders MAY support other compression algorithms. 426 5. Protocol Extension Points 428 The Metadata Query Protocol is extensible using the following 429 protocol extension points: 431 o Profiles of this specification may assign semantics to specific 432 identifiers, or to identifiers structured in particular ways. 434 o Profiles of this specification may define additional paths (other 435 than "entities" and "entities/") below the base URL. 437 6. Security Considerations 439 6.1. Integrity 441 As metadata often contains information necessary for the secure 442 operation of interacting services it is RECOMMENDED that some form of 443 content integrity checking be performed. This may include the use of 444 TLS at the transport layer, digital signatures present within the 445 metadata document, or any other such mechanism. 447 6.2. Confidentiality 449 In many cases service metadata is public information and therefore 450 confidentiality is not required. In the cases where such 451 functionality is required, it is RECOMMENDED that both the requester 452 and responder support TLS. Other mechanisms, such as XML encryption, 453 MAY also be supported. 455 6.3. Authentication 457 All responders which require client authentication to view retrieved 458 information MUST support the use of HTTP basic authentication 459 ([RFC7235], [RFC7617]) over TLS. Responders SHOULD also support the 460 use of X.509 client certificate authentication. 462 7. IANA Considerations 464 This document has no actions for IANA. 466 8. Acknowledgements 468 The editor would like to acknowledge the following individuals for 469 their contributions to this document: 471 Scott Cantor (The Ohio State University) 473 Leif Johansson (SUNET) 474 Thomas Lenggenhager (SWITCH) 476 Joe St Sauver (University of Oregon) 478 Tom Scavo (Internet2) 480 Special acknowledgement is due to Chad LaJoie (Covisint) for his work 481 in editing previous versions of this specification. 483 9. References 485 9.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 493 Protocol (HTTP/1.1): Message Syntax and Routing", 494 RFC 7230, DOI 10.17487/RFC7230, June 2014, 495 . 497 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 498 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 499 DOI 10.17487/RFC7231, June 2014, 500 . 502 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 503 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 504 DOI 10.17487/RFC7232, June 2014, 505 . 507 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 508 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 509 RFC 7234, DOI 10.17487/RFC7234, June 2014, 510 . 512 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 513 Protocol (HTTP/1.1): Authentication", RFC 7235, 514 DOI 10.17487/RFC7235, June 2014, 515 . 517 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 518 RFC 7617, DOI 10.17487/RFC7617, September 2015, 519 . 521 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 522 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 523 May 2017, . 525 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 526 Resource Identifier (URI): Generic Syntax", STD 66, 527 RFC 3986, DOI 10.17487/RFC3986, January 2005, 528 . 530 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 531 Specifications: ABNF", STD 68, RFC 5234, 532 DOI 10.17487/RFC5234, January 2008, 533 . 535 9.2. Informative References 537 [md-query] 538 Young, I., Ed., "md-query Project", 539 . 541 [MDX.list] 542 Young, I., Ed., "MDX Mailing List", 543 . 545 [REFEDS] Research and Education Federations, "REFEDS Home Page", 546 . 548 [REFEDS.agreement] 549 Research and Education Federations, "REFEDS Participant's 550 Agreement", 551 . 553 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 554 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 555 July 2007, . 557 Appendix A. Change Log (to be removed by RFC Editor before publication) 559 A.1. Since draft-lajoie-md-query-01 561 Adopted as base for draft-young-md-query-00. 563 Updated author and list of contributors. 565 Changed ipr from "pre5378Trust200902" to "trust200902", submission 566 type from IETF to independent and category from experimental to 567 informational. 569 Added empty IANA considerations section. 571 Minor typographical nits but (intentionally) no substantive content 572 changes. 574 A.2. Since draft-young-md-query-00 576 Split into two documents: this one is as agnostic as possible around 577 questions such as metadata format and higher level protocol use 578 cases, a new layered document describes the detailed requirements for 579 SAML support. 581 Rewrite Section 3.2.1 to clarify construction of the request URL and 582 its relationship to the base URL. 584 Added Section 2.1 to clarify that the transport protocol underlying 585 HTTP may be either TCP or SSL/TLS. 587 Clarify position on HTTP versions (Section 2.2) which may be used to 588 underly this protocol. 590 Added Change Log modelled on draft-ietf-httpbis-http2. 592 Added a reference to [STD68]. Use ABNF to describe request syntax. 593 Replace transformed identifier concept with extended identifiers 594 (this also resulted in the removal of any discussion of specific 595 transformed identifier formats). Add grammar to distinguish basic 596 from extended identifiers. 598 Changed the required response when the result can not be validly 599 expressed in the requested format from 500 to 406. 601 Removed the '+' operator and all references to multiple identifiers 602 in queries. If more complex queries are required, these will be 603 reintroduced at a different path under the base URL. 605 Added a section describing Protocol Extension Points. 607 A.3. Since draft-young-md-query-01 609 Added REFEDS RFC stream boilerplate. 611 Tidied up some normative language. 613 A.4. Since draft-young-md-query-02 615 Introduced a normative reference to [STD66]. 617 Reworked the definition of the base URL so that a non-empty path 618 ending with '/' is required. This allows the definition of request 619 URLs to be simplified. 621 Clarified the definition of the base URL to exclude a query 622 component; corrected the terminology for the fragment identifier 623 component. 625 Added the definition for the query for all entities in Section 3.2.2. 627 Corrected an example in Section 3.2.4 to include the required double 628 quotes in the value of an ETag header. Added text to clarify the 629 base URL and identifier being used in the example. 631 Simplified the definition of identifiers, so that any non-empty 632 identifier is accepted and no semantics are defined for particular 633 structures. Extended syntaxes such as the "{sha1}" notation for 634 transformed identifiers are now left to profiles. 636 Remove incidental references to SSL. 638 Remove status code 501 ("not implemented") as it is no longer 639 referenced. 641 A.5. Since draft-young-md-query-03 643 Correct a typo in the identifier grammar. 645 A.6. Since draft-young-md-query-04 647 Updated to rely on the new definition of HTTP/1.1 in [RFC7230] et 648 seq. instead of RFC 2616. 650 Corrected Section 3.2.3 to indicate that the request contains an 651 Accept header, not a Content-Type header. 653 Added an Editorial Note to help direct readers back to the 654 discussion. 656 A.7. Since draft-young-md-query-05 658 Remove unnecessary percent-encoding of a ':' character in the example 659 in Section 3.2.4. 661 Removed use of the ambiguous term "URL-encoded" in Section 3.2.1. 662 Instead, indicate that the encoding must correspond to the rules for 663 encoding a URL path segment specifically, and call out some of the 664 more important implications arising from that. Added a new example 665 illustrating these implications. 667 Updated the description of conditional retrieval in Section 4.1 to 668 make the use of a 304 (Not Modified) status code a normative but non- 669 mandatory obligation on the responder, not simply a description of 670 what the requester will receive. 672 A.8. Since draft-young-md-query-06 674 No substantive changes. 676 A.9. Since draft-young-md-query-07 678 No substantive changes. 680 A.10. Since draft-young-md-query-08 682 Modernise normative language to include [RFC8174]. 684 Reference [RFC7617] instead of the Internet-Draft. 686 Improved references to RFCs. 688 A.11. Since draft-young-md-query-09 690 No substantive changes. 692 A.12. Since draft-young-md-query-10 694 No substantive changes. 696 A.13. Since draft-young-md-query-11 698 No substantive changes. 700 Author's Address 702 Ian A. Young (editor) 703 Independent 705 EMail: ian@iay.org.uk