idnits 2.17.1 draft-young-md-query-10.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 15, 2019) is 1921 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 15, 2019 5 Expires: July 19, 2019 7 Metadata Query Protocol 8 draft-young-md-query-10 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.11. 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, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 109 1. Introduction 111 Many clients of web-based services are capable of consuming 112 descriptive metadata about a service in order to customize or obtain 113 information about the client's connection parameters. While the form 114 of the metadata (e.g., JSON, XML) and content varies between services 115 this document specifies a set of semantics for HTTP ([RFC7230] et 116 seq.) that allow clients to rely on certain behavior. The defined 117 behavior is meant to make it easy for clients to perform queries, to 118 be efficient for both requesters and responders, and to allow the 119 responder to scale in various ways. 121 The Research and Education Federations group ([REFEDS]) is the voice 122 that articulates the mutual needs of research and education identity 123 federations worldwide. It aims to represent the requirements of 124 research and education in the ever-growing space of access and 125 identity management. 127 From time to time REFEDS will wish to publish a document in the 128 Internet RFC series. Such documents will be published as part of the 129 RFC Independent Submission Stream [RFC4844]; however the REFEDS 130 working group sign-off process will have been followed for these 131 documents, as described in the REFEDS Participant's Agreement 132 [REFEDS.agreement]. 134 This document is a product of the REFEDS Working Group process. 136 1.1. Notation and Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 This document makes use of the Augmented BNF metalanguage defined in 145 [STD68]. 147 1.2. Terminology 149 entity: A single logical construct for which metadata may be 150 asserted. Generally this is a network accessible service. 152 metadata: A machine readable description of certain entity 153 characteristics. Generally metadata provides information such as 154 end point references, service contact information, etc. 156 2. Protocol Transport 158 The metadata query protocol seeks to fully employ the features of the 159 HTTP protocol. Additionally this specification makes mandatory some 160 optional HTTP features. 162 2.1. Transport Protocol 164 The metadata query protocol makes use of the HTTP protocol 165 ([RFC7230]) to transmit requests and responses. The underlying HTTP 166 connection MAY make use of any appropriate transport protocol. In 167 particular, the HTTP connection MAY make use of either TCP or TLS at 168 the transport layer. See the Security Considerations section for 169 guidance in choosing an appropriate transport protocol. 171 2.2. HTTP Version 173 Requests from clients MUST NOT use an HTTP version prior to version 174 1.1. Responders MUST reply to such requests using status code 505, 175 "HTTP Version Not Supported". 177 Protocol responders MUST support requests using HTTP version 1.1, and 178 MAY support later versions. 180 2.3. HTTP Method 182 All metadata query requests MUST use the GET method. 184 2.4. Request Headers 186 All metadata query requests MUST include the following HTTP headers: 188 Accept - this header MUST contain the content-type identifying the 189 type, or form, of metadata to be retrieved. See section 5.3.2 of 190 [RFC7231]. 192 All metadata query requests SHOULD include the following HTTP 193 headers: 195 Accept-Charset, see section 5.3.3 of [RFC7231] 197 Accept-Encoding, see section 5.3.4 of [RFC7231] 199 A metadata request to the same URL, after an initial request, MUST 200 include the following header: 202 If-None-Match, see section 3.2 of [RFC7232]. 204 2.5. Response Headers 206 All successful metadata query responses (even those that return no 207 results) MUST include the following headers: 209 Content-Encoding - required if, and only if, content is 210 compressed. See section 3.1.2.2 of [RFC7231]. 212 Content-Type, see section 3.1.1.5 of [RFC7231]. 214 ETag, see section 2.3 of [RFC7232]. 216 All metadata retrieval responses SHOULD include the following 217 headers: 219 Cache-Control, see section 5.2 of [RFC7234]. 221 Content-Length, see section 3.3.2 of [RFC7230] 223 Last-Modified, see section 2.2 of [RFC7232]. 225 2.6. Status Codes 227 This protocol uses the following HTTP status codes: 229 200 "OK" - standard response code when returning requested 230 metadata 232 304 "Not Modified" - response code indicating requested metadata 233 has not been updated since the last request 235 400 "Bad Request" - response code indicating that the requester's 236 request was malformed in some fashion 238 401 "Unauthorized" - response code indicating the request must be 239 authenticated before requesting metadata 240 404 "Not Found" - indicates that the requested metadata could not 241 be found; this MUST NOT be used in order to indicate a general 242 service error. 244 405 "Method Not Allowed" - response code indicating that a non-GET 245 method was used 247 406 "Not Acceptable" - response code indicating that metadata is 248 not available in the request content-type 250 505 "HTTP Version Not Supported" - response code indicating that 251 HTTP/1.1 was not used 253 2.7. Base URL 255 Requests defined in this document are performed by issuing an HTTP 256 GET request to a particular URL ([STD66]). The final component of 257 the path to which requests are issued is defined by the requests 258 specified within this document. A base URL precedes such paths. 259 Such a base URL: 261 o MUST contain the scheme and authority components. 263 o MUST contain a path component ending with a slash ('/') character. 265 o MUST NOT include a query component. 267 o MUST NOT include a fragment identifier component. 269 2.8. Content Negotiation 271 As there may be many representations for a given piece of metadata, 272 agent-driven content negotiation is used to ensure the proper 273 representation is delivered to the requester. In addition to the 274 required usage of the Accept header a responder SHOULD also support 275 the use of the Accept-Charset header. 277 3. Metadata Query Protocol 279 The metadata query protocol retrieves metadata either for all 280 entities known to the responder or for a named collection based on a 281 single "tag" or "keyword" identifier. A request returns information 282 for none, one, or a collection of entities. 284 3.1. Identifiers 286 The query protocol uses identifiers to "tag" metadata for single- and 287 multi-entity metadata collections. The assignment of such 288 identifiers to a particular metadata document is the responsibility 289 of the query responder. If a metadata collection already contains a 290 well known identifier it is RECOMMENDED that such a natural 291 identifier is used when possible. Any given metadata collection MAY 292 have more than one identifier associated with it. 294 An identifier used in the query protocol is a non-empty sequence of 295 arbitrary 8-bit characters: 297 id = 1*idchar 298 idchar = %x00-ff ; any encodable character 300 3.2. Protocol 302 3.2.1. Request by Identifier 304 A metadata query request for all entities tagged with a particular 305 identifier is performed by issuing an HTTP GET request to a URL 306 constructed as the concatenation of the following components: 308 o The responder's base URL. 310 o The string "entities/". 312 o A single identifier, percent-encoded appropriately for use as a 313 URL path segment (see sections 2.1 and 3.3 of [STD66]). 315 For example, with a base URL of "http://example.org/mdq/", a query 316 for the identifier "foo" would be performed by an HTTP GET request to 317 the following URL: 319 http://example.org/mdq/entities/foo 321 Correct encoding of the identifier as a URL path segment is critical 322 for interoperability. In particular: 324 The character '/' MUST be percent-encoded. 326 The space character MUST be encoded as '%20' and MUST NOT be 327 encoded as '+' as would be required in a query parameter. 329 For example, with a base URL of "http://example.org/mdq/", a query 330 for the identifier ""blue/green+light blue"" would be performed by an 331 HTTP GET request to the following URL: 333 http://example.org/mdq/entities/blue%2Fgreen+light%20blue 335 3.2.2. Request All Entities 337 A metadata query request for all entities known to the responder is 338 performed by issuing an HTTP GET request to a URL constructed as the 339 concatenation of the following components: 341 o The responder's base URL. 343 o The string "entities". 345 For example, with a base URL of "http://example.org/mdq/", a query 346 for all entities would be performed by an HTTP GET request to the 347 following URL: 349 http://example.org/mdq/entities 351 3.2.3. Response 353 The response to a metadata query request MUST be a document that 354 provides metadata for the given request in the format described by 355 the request's Accept header. 357 The responder is responsible for ensuring that the metadata returned 358 is valid. If the responder can not create a valid document it MUST 359 respond with a 406 status code. An example of such an error would be 360 the case where the result of the query is metadata for multiple 361 entities but the request content type does not support returning 362 multiple results in a single document. 364 3.2.4. Example Request and Response 366 The following example demonstrates a metadata query request using a 367 base URL of "http://metadata.example.org/service/" and the identifier 368 "http://example.org/idp". 370 GET /service/entities/http:%2F%2Fexample.org%2Fidp HTTP/1.1 371 Host: metadata.example.org 372 Accept: application/samlmetadata+xml 374 Example Metadata Query Request 376 HTTP/1.x 200 OK 377 Content-Type: application/samlmetadata+xml 378 ETag: "abcdefg" 379 Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT 380 Content-Length: 1234 382 383 385 .... 387 Example Metadata Query Response 389 4. Efficient Retrieval and Caching 391 4.1. Conditional Retrieval 393 Upon a successful response the responder MUST return an ETag header 394 and MAY return a Last-Modified header as well. Requesters SHOULD use 395 either or both, with the ETag being preferred, in any subsequent 396 requests for the same resource. 398 In the event that a resource has not changed since the previous 399 request, the responder SHOULD send a 304 (Not Modified) status code 400 as a response. 402 4.2. Content Caching 404 Responders SHOULD include cache control information with successful 405 (200 status code) responses, assuming the responder knows when 406 retrieved metadata is meant to expire. The responder SHOULD also 407 include cache control information with 404 Not Found responses. This 408 allows the requester to create and maintain a negative-response 409 cache. When cache controls are used only the 'max-age' directive 410 SHOULD be used. 412 4.3. Content Compression 414 As should be apparent from the required request and response headers 415 this protocol encourages the use of content compression. This is in 416 recognition that some metadata documents can be quite large or 417 fetched with relatively high frequency. 419 Requesters SHOULD support, and advertise support for, gzip 420 compression unless such usage would put exceptional demands on 421 constrained environments. Responders MUST support gzip compression. 422 Requesters and responders MAY support other compression algorithms. 424 5. Protocol Extension Points 426 The Metadata Query Protocol is extensible using the following 427 protocol extension points: 429 o Profiles of this specification may assign semantics to specific 430 identifiers, or to identifiers structured in particular ways. 432 o Profiles of this specification may define additional paths (other 433 than "entities" and "entities/") below the base URL. 435 6. Security Considerations 437 6.1. Integrity 439 As metadata often contains information necessary for the secure 440 operation of interacting services it is RECOMMENDED that some form of 441 content integrity checking be performed. This may include the use of 442 TLS at the transport layer, digital signatures present within the 443 metadata document, or any other such mechanism. 445 6.2. Confidentiality 447 In many cases service metadata is public information and therefore 448 confidentiality is not required. In the cases where such 449 functionality is required, it is RECOMMENDED that both the requester 450 and responder support TLS. Other mechanisms, such as XML encryption, 451 MAY also be supported. 453 6.3. Authentication 455 All responders which require client authentication to view retrieved 456 information MUST support the use of HTTP basic authentication 457 ([RFC7235], [RFC7617]) over TLS. Responders SHOULD also support the 458 use of X.509 client certificate authentication. 460 7. IANA Considerations 462 This document has no actions for IANA. 464 8. Acknowledgements 466 The editor would like to acknowledge the following individuals for 467 their contributions to this document: 469 Scott Cantor (The Ohio State University) 471 Leif Johansson (SUNET) 472 Thomas Lenggenhager (SWITCH) 474 Joe St Sauver (University of Oregon) 476 Tom Scavo (Internet2) 478 Special acknowledgement is due to Chad LaJoie (Covisint) for his work 479 in editing previous versions of this specification. 481 9. References 483 9.1. Normative References 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 491 Protocol (HTTP/1.1): Message Syntax and Routing", 492 RFC 7230, DOI 10.17487/RFC7230, June 2014, 493 . 495 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 496 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 497 DOI 10.17487/RFC7231, June 2014, 498 . 500 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 501 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 502 DOI 10.17487/RFC7232, June 2014, 503 . 505 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 506 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 507 RFC 7234, DOI 10.17487/RFC7234, June 2014, 508 . 510 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 511 Protocol (HTTP/1.1): Authentication", RFC 7235, 512 DOI 10.17487/RFC7235, June 2014, 513 . 515 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 516 RFC 7617, DOI 10.17487/RFC7617, September 2015, 517 . 519 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 520 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 521 May 2017, . 523 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 524 Resource Identifier (URI): Generic Syntax", STD 66, 525 RFC 3986, DOI 10.17487/RFC3986, January 2005, 526 . 528 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 529 Specifications: ABNF", STD 68, RFC 5234, 530 DOI 10.17487/RFC5234, January 2008, 531 . 533 9.2. Informative References 535 [md-query] 536 Young, I., Ed., "md-query Project", 537 . 539 [MDX.list] 540 Young, I., Ed., "MDX Mailing List", 541 . 543 [REFEDS] Research and Education Federations, "REFEDS Home Page", 544 . 546 [REFEDS.agreement] 547 Research and Education Federations, "REFEDS Participant's 548 Agreement", 549 . 551 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 552 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 553 July 2007, . 555 Appendix A. Change Log (to be removed by RFC Editor before publication) 557 A.1. Since draft-lajoie-md-query-01 559 Adopted as base for draft-young-md-query-00. 561 Updated author and list of contributors. 563 Changed ipr from "pre5378Trust200902" to "trust200902", submission 564 type from IETF to independent and category from experimental to 565 informational. 567 Added empty IANA considerations section. 569 Minor typographical nits but (intentionally) no substantive content 570 changes. 572 A.2. Since draft-young-md-query-00 574 Split into two documents: this one is as agnostic as possible around 575 questions such as metadata format and higher level protocol use 576 cases, a new layered document describes the detailed requirements for 577 SAML support. 579 Rewrite Section 3.2.1 to clarify construction of the request URL and 580 its relationship to the base URL. 582 Added Section 2.1 to clarify that the transport protocol underlying 583 HTTP may be either TCP or SSL/TLS. 585 Clarify position on HTTP versions (Section 2.2) which may be used to 586 underly this protocol. 588 Added Change Log modelled on draft-ietf-httpbis-http2. 590 Added a reference to [STD68]. Use ABNF to describe request syntax. 591 Replace transformed identifier concept with extended identifiers 592 (this also resulted in the removal of any discussion of specific 593 transformed identifier formats). Add grammar to distinguish basic 594 from extended identifiers. 596 Changed the required response when the result can not be validly 597 expressed in the requested format from 500 to 406. 599 Removed the '+' operator and all references to multiple identifiers 600 in queries. If more complex queries are required, these will be 601 reintroduced at a different path under the base URL. 603 Added a section describing Protocol Extension Points. 605 A.3. Since draft-young-md-query-01 607 Added REFEDS RFC stream boilerplate. 609 Tidied up some normative language. 611 A.4. Since draft-young-md-query-02 613 Introduced a normative reference to [STD66]. 615 Reworked the definition of the base URL so that a non-empty path 616 ending with '/' is required. This allows the definition of request 617 URLs to be simplified. 619 Clarified the definition of the base URL to exclude a query 620 component; corrected the terminology for the fragment identifier 621 component. 623 Added the definition for the query for all entities in Section 3.2.2. 625 Corrected an example in Section 3.2.4 to include the required double 626 quotes in the value of an ETag header. Added text to clarify the 627 base URL and identifier being used in the example. 629 Simplified the definition of identifiers, so that any non-empty 630 identifier is accepted and no semantics are defined for particular 631 structures. Extended syntaxes such as the "{sha1}" notation for 632 transformed identifiers are now left to profiles. 634 Remove incidental references to SSL. 636 Remove status code 501 ("not implemented") as it is no longer 637 referenced. 639 A.5. Since draft-young-md-query-03 641 Correct a typo in the identifier grammar. 643 A.6. Since draft-young-md-query-04 645 Updated to rely on the new definition of HTTP/1.1 in [RFC7230] et 646 seq. instead of RFC 2616. 648 Corrected Section 3.2.3 to indicate that the request contains an 649 Accept header, not a Content-Type header. 651 Added an Editorial Note to help direct readers back to the 652 discussion. 654 A.7. Since draft-young-md-query-05 656 Remove unnecessary percent-encoding of a ':' character in the example 657 in Section 3.2.4. 659 Removed use of the ambiguous term "URL-encoded" in Section 3.2.1. 660 Instead, indicate that the encoding must correspond to the rules for 661 encoding a URL path segment specifically, and call out some of the 662 more important implications arising from that. Added a new example 663 illustrating these implications. 665 Updated the description of conditional retrieval in Section 4.1 to 666 make the use of a 304 (Not Modified) status code a normative but non- 667 mandatory obligation on the responder, not simply a description of 668 what the requester will receive. 670 A.8. Since draft-young-md-query-06 672 No substantive changes. 674 A.9. Since draft-young-md-query-07 676 No substantive changes. 678 A.10. Since draft-young-md-query-08 680 Modernise normative language to include [RFC8174]. 682 Reference [RFC7617] instead of the Internet-Draft. 684 Improved references to RFCs. 686 A.11. Since draft-young-md-query-09 688 No substantive changes. 690 Author's Address 692 Ian A. Young (editor) 693 Independent 695 EMail: ian@iay.org.uk