idnits 2.17.1 draft-young-md-query-16.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 (10 January 2022) is 836 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.A. Young, Ed. 3 Internet-Draft Independent 4 Intended status: Informational 10 January 2022 5 Expires: 14 July 2022 7 Metadata Query Protocol 8 draft-young-md-query-16 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.17. 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 14 July 2022. 47 Copyright Notice 49 Copyright (c) 2022 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 (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Notation and Conventions . . . . . . . . . . . . . . . . 4 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Protocol Transport . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Transport Protocol . . . . . . . . . . . . . . . . . . . 4 65 2.2. HTTP Version . . . . . . . . . . . . . . . . . . . . . . 4 66 2.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.4. Request Headers . . . . . . . . . . . . . . . . . . . . . 5 68 2.5. Response Headers . . . . . . . . . . . . . . . . . . . . 5 69 2.6. Status Codes . . . . . . . . . . . . . . . . . . . . . . 5 70 2.7. Base URL . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.8. Content Negotiation . . . . . . . . . . . . . . . . . . . 6 72 3. Metadata Query Protocol . . . . . . . . . . . . . . . . . . . 7 73 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.2.1. Request by Identifier . . . . . . . . . . . . . . . . 7 76 3.2.2. Request All Entities . . . . . . . . . . . . . . . . 8 77 3.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2.4. Example Request and Response . . . . . . . . . . . . 8 79 4. Efficient Retrieval and Caching . . . . . . . . . . . . . . . 9 80 4.1. Conditional Retrieval . . . . . . . . . . . . . . . . . . 9 81 4.2. Content Caching . . . . . . . . . . . . . . . . . . . . . 9 82 4.3. Content Compression . . . . . . . . . . . . . . . . . . . 9 83 5. Protocol Extension Points . . . . . . . . . . . . . . . . . . 10 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 6.1. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 86 6.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 87 6.3. Authentication . . . . . . . . . . . . . . . . . . . . . 10 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 92 9.2. Informative References . . . . . . . . . . . . . . . . . 12 93 Appendix A. Change Log (to be removed by RFC Editor before 94 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 A.14. Since draft-young-md-query-12 . . . . . . . . . . . . . . 16 110 A.15. Since draft-young-md-query-13 . . . . . . . . . . . . . . 16 111 A.16. Since draft-young-md-query-14 . . . . . . . . . . . . . . 16 112 A.17. Since draft-young-md-query-15 . . . . . . . . . . . . . . 16 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 115 1. Introduction 117 Many clients of web-based services are capable of consuming 118 descriptive metadata about a service in order to customize or obtain 119 information about the client's connection parameters. While the form 120 of the metadata (e.g., JSON, XML) and content varies between services 121 this document specifies a set of semantics for HTTP ([RFC7230] et 122 seq.) that allow clients to rely on certain behavior. The defined 123 behavior is meant to make it easy for clients to perform queries, to 124 be efficient for both requesters and responders, and to allow the 125 responder to scale in various ways. 127 The Research and Education Federations group ([REFEDS]) is the voice 128 that articulates the mutual needs of research and education identity 129 federations worldwide. It aims to represent the requirements of 130 research and education in the ever-growing space of access and 131 identity management. 133 From time to time REFEDS will wish to publish a document in the 134 Internet RFC series. Such documents will be published as part of the 135 RFC Independent Submission Stream [RFC4844]; however the REFEDS 136 working group sign-off process will have been followed for these 137 documents, as described in the REFEDS Participant's Agreement 138 [REFEDS.agreement]. 140 This document is a product of the REFEDS Working Group process. 142 1.1. Notation and Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 This document makes use of the Augmented BNF metalanguage defined in 151 [STD68]. 153 1.2. Terminology 155 entity: A single logical construct for which metadata may be 156 asserted. Generally this is a network accessible service. 158 metadata: A machine readable description of certain entity 159 characteristics. Generally metadata provides information such as 160 end point references, service contact information, etc. 162 2. Protocol Transport 164 The metadata query protocol seeks to fully employ the features of the 165 HTTP protocol. Additionally this specification makes mandatory some 166 optional HTTP features. 168 2.1. Transport Protocol 170 The metadata query protocol makes use of the HTTP protocol 171 ([RFC7230]) to transmit requests and responses. The underlying HTTP 172 connection MAY make use of any appropriate transport protocol. In 173 particular, the HTTP connection MAY make use of either TCP or TLS at 174 the transport layer. See the Security Considerations section for 175 guidance in choosing an appropriate transport protocol. 177 2.2. HTTP Version 179 Requests from clients MUST NOT use an HTTP version prior to version 180 1.1. Responders MUST reply to such requests using status code 505, 181 "HTTP Version Not Supported". 183 Protocol responders MUST support requests using HTTP version 1.1, and 184 MAY support later versions. 186 2.3. HTTP Method 188 All metadata query requests MUST use the GET method. 190 2.4. Request Headers 192 All metadata query requests MUST include the following HTTP headers: 194 Accept - this header MUST contain the content-type identifying the 195 type, or form, of metadata to be retrieved. See section 5.3.2 of 196 [RFC7231]. 198 All metadata query requests SHOULD include the following HTTP 199 headers: 201 Accept-Charset, see section 5.3.3 of [RFC7231] 203 Accept-Encoding, see section 5.3.4 of [RFC7231] 205 A metadata request to the same URL, after an initial request, MUST 206 include the following header: 208 If-None-Match, see section 3.2 of [RFC7232]. 210 2.5. Response Headers 212 All successful metadata query responses (even those that return no 213 results) MUST include the following headers: 215 Content-Encoding - required if, and only if, content is 216 compressed. See section 3.1.2.2 of [RFC7231]. 218 Content-Type, see section 3.1.1.5 of [RFC7231]. 220 ETag, see section 2.3 of [RFC7232]. 222 All metadata retrieval responses SHOULD include the following 223 headers: 225 Cache-Control, see section 5.2 of [RFC7234]. 227 Content-Length, see section 3.3.2 of [RFC7230] 229 Last-Modified, see section 2.2 of [RFC7232]. 231 2.6. Status Codes 233 This protocol uses the following HTTP status codes: 235 200 "OK" - standard response code when returning requested 236 metadata 237 304 "Not Modified" - response code indicating requested metadata 238 has not been updated since the last request 240 400 "Bad Request" - response code indicating that the requester's 241 request was malformed in some fashion 243 401 "Unauthorized" - response code indicating the request must be 244 authenticated before requesting metadata 246 404 "Not Found" - indicates that the requested metadata could not 247 be found; this MUST NOT be used in order to indicate a general 248 service error. 250 405 "Method Not Allowed" - response code indicating that a non-GET 251 method was used 253 406 "Not Acceptable" - response code indicating that metadata is 254 not available in the request content-type 256 505 "HTTP Version Not Supported" - response code indicating that 257 HTTP/1.1 was not used 259 2.7. Base URL 261 Requests defined in this document are performed by issuing an HTTP 262 GET request to a particular URL ([STD66]). The final component of 263 the path to which requests are issued is defined by the requests 264 specified within this document. A base URL precedes such paths. 265 Such a base URL: 267 * MUST contain the scheme and authority components. 269 * MUST contain a path component ending with a slash ('/') character. 271 * MUST NOT include a query component. 273 * MUST NOT include a fragment identifier component. 275 2.8. Content Negotiation 277 As there may be many representations for a given piece of metadata, 278 agent-driven content negotiation is used to ensure the proper 279 representation is delivered to the requester. In addition to the 280 required usage of the Accept header a responder SHOULD also support 281 the use of the Accept-Charset header. 283 3. Metadata Query Protocol 285 The metadata query protocol retrieves metadata either for all 286 entities known to the responder or for a named collection based on a 287 single "tag" or "keyword" identifier. A request returns information 288 for none, one, or a collection of entities. 290 3.1. Identifiers 292 The query protocol uses identifiers to "tag" metadata for single- and 293 multi-entity metadata collections. The assignment of such 294 identifiers to a particular metadata document is the responsibility 295 of the query responder. If a metadata collection already contains a 296 well known identifier it is RECOMMENDED that such a natural 297 identifier is used when possible. Any given metadata collection MAY 298 have more than one identifier associated with it. 300 An identifier used in the query protocol is a non-empty sequence of 301 arbitrary 8-bit characters: 303 id = 1*idchar 304 idchar = %x00-ff ; any encodable character 306 3.2. Protocol 308 3.2.1. Request by Identifier 310 A metadata query request for all entities tagged with a particular 311 identifier is performed by issuing an HTTP GET request to a URL 312 constructed as the concatenation of the following components: 314 * The responder's base URL. 316 * The string "entities/". 318 * A single identifier, percent-encoded appropriately for use as a 319 URL path segment (see sections 2.1 and 3.3 of [STD66]). 321 For example, with a base URL of http://example.org/mdq/, a query for 322 the identifier foo would be performed by an HTTP GET request to the 323 following URL: 325 http://example.org/mdq/entities/foo 327 Correct encoding of the identifier as a URL path segment is critical 328 for interoperability. In particular: 330 The character '/' MUST be percent-encoded. 332 The space character MUST be encoded as '%20' and MUST NOT be 333 encoded as '+' as would be required in a query parameter. 335 For example, with a base URL of http://example.org/mdq/, a query for 336 the identifier "blue/green+light blue" would be performed by an HTTP 337 GET request to the following URL: 339 http://example.org/mdq/entities/blue%2Fgreen+light%20blue 341 3.2.2. Request All Entities 343 A metadata query request for all entities known to the responder is 344 performed by issuing an HTTP GET request to a URL constructed as the 345 concatenation of the following components: 347 * The responder's base URL. 349 * The string "entities". 351 For example, with a base URL of http://example.org/mdq/, a query for 352 all entities would be performed by an HTTP GET request to the 353 following URL: 355 http://example.org/mdq/entities 357 3.2.3. Response 359 The response to a metadata query request MUST be a document that 360 provides metadata for the given request in the format described by 361 the request's Accept header. 363 The responder is responsible for ensuring that the metadata returned 364 is valid. If the responder can not create a valid document it MUST 365 respond with a 406 status code. An example of such an error would be 366 the case where the result of the query is metadata for multiple 367 entities but the request content type does not support returning 368 multiple results in a single document. 370 3.2.4. Example Request and Response 372 The following example demonstrates a metadata query request using a 373 base URL of http://metadata.example.org/service/ and the identifier 374 http://example.org/idp. 376 GET /service/entities/http:%2F%2Fexample.org%2Fidp HTTP/1.1 377 Host: metadata.example.org 378 Accept: application/samlmetadata+xml 379 Figure 1: Example Metadata Query Request 381 HTTP/1.x 200 OK 382 Content-Type: application/samlmetadata+xml 383 ETag: "abcdefg" 384 Last-Modified: Thu, 15 Apr 2010 12:45:26 GMT 385 Content-Length: 1234 387 388 390 .... 392 Figure 2: Example Metadata Query Response 394 4. Efficient Retrieval and Caching 396 4.1. Conditional Retrieval 398 Upon a successful response the responder MUST return an ETag header 399 and MAY return a Last-Modified header as well. Requesters SHOULD use 400 either or both, with the ETag being preferred, in any subsequent 401 requests for the same resource. 403 In the event that a resource has not changed since the previous 404 request, the responder SHOULD send a 304 (Not Modified) status code 405 as a response. 407 4.2. Content Caching 409 Responders SHOULD include cache control information with successful 410 (200 status code) responses, assuming the responder knows when 411 retrieved metadata is meant to expire. The responder SHOULD also 412 include cache control information with 404 Not Found responses. This 413 allows the requester to create and maintain a negative-response 414 cache. When cache controls are used only the 'max-age' directive 415 SHOULD be used. 417 4.3. Content Compression 419 As should be apparent from the required request and response headers 420 this protocol encourages the use of content compression. This is in 421 recognition that some metadata documents can be quite large or 422 fetched with relatively high frequency. 424 Requesters SHOULD support, and advertise support for, gzip 425 compression unless such usage would put exceptional demands on 426 constrained environments. Responders MUST support gzip compression. 427 Requesters and responders MAY support other compression algorithms. 429 5. Protocol Extension Points 431 The Metadata Query Protocol is extensible using the following 432 protocol extension points: 434 * Profiles of this specification may assign semantics to specific 435 identifiers, or to identifiers structured in particular ways. 437 * Profiles of this specification may define additional paths (other 438 than entities and entities/) below the base URL. 440 6. Security Considerations 442 6.1. Integrity 444 As metadata often contains information necessary for the secure 445 operation of interacting services it is RECOMMENDED that some form of 446 content integrity checking be performed. This may include the use of 447 TLS at the transport layer, digital signatures present within the 448 metadata document, or any other such mechanism. 450 6.2. Confidentiality 452 In many cases service metadata is public information and therefore 453 confidentiality is not required. In the cases where such 454 functionality is required, it is RECOMMENDED that both the requester 455 and responder support TLS. Other mechanisms, such as XML encryption, 456 MAY also be supported. 458 6.3. Authentication 460 All responders which require client authentication to view retrieved 461 information MUST support the use of HTTP basic authentication 462 ([RFC7235], [RFC7617]) over TLS. Responders SHOULD also support the 463 use of X.509 client certificate authentication. 465 7. IANA Considerations 467 This document has no actions for IANA. 469 8. Acknowledgements 471 The editor would like to acknowledge the following individuals for 472 their contributions to this document: 474 Scott Cantor (The Ohio State University) 476 Leif Johansson (SUNET) 478 Thomas Lenggenhager (SWITCH) 480 Joe St Sauver (University of Oregon) 482 Tom Scavo (Internet2) 484 Special acknowledgement is due to Chad LaJoie (Covisint) for his work 485 in editing previous versions of this specification. 487 9. References 489 9.1. Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", BCP 14, RFC 2119, 493 DOI 10.17487/RFC2119, March 1997, 494 . 496 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 497 Protocol (HTTP/1.1): Message Syntax and Routing", 498 RFC 7230, DOI 10.17487/RFC7230, June 2014, 499 . 501 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 502 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 503 DOI 10.17487/RFC7231, June 2014, 504 . 506 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 507 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 508 DOI 10.17487/RFC7232, June 2014, 509 . 511 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 512 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 513 RFC 7234, DOI 10.17487/RFC7234, June 2014, 514 . 516 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 517 Protocol (HTTP/1.1): Authentication", RFC 7235, 518 DOI 10.17487/RFC7235, June 2014, 519 . 521 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 522 RFC 7617, DOI 10.17487/RFC7617, September 2015, 523 . 525 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 526 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 527 May 2017, . 529 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 530 Resource Identifier (URI): Generic Syntax", STD 66, 531 RFC 3986, DOI 10.17487/RFC3986, January 2005, 532 . 534 [STD68] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 535 Specifications: ABNF", STD 68, RFC 5234, 536 DOI 10.17487/RFC5234, January 2008, 537 . 539 9.2. Informative References 541 [md-query] Young, I.A., Ed., "md-query Project", 542 . 544 [MDX.list] Young, I.A., Ed., "MDX Mailing List", 545 . 547 [REFEDS] Research and Education Federations, "REFEDS Home Page", 548 . 550 [REFEDS.agreement] 551 Research and Education Federations, "REFEDS Participant's 552 Agreement", 553 . 555 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC 556 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, 557 July 2007, . 559 Appendix A. Change Log (to be removed by RFC Editor before publication) 561 A.1. Since draft-lajoie-md-query-01 563 Adopted as base for draft-young-md-query-00. 565 Updated author and list of contributors. 567 Changed ipr from "pre5378Trust200902" to "trust200902", submission 568 type from IETF to independent and category from experimental to 569 informational. 571 Added empty IANA considerations section. 573 Minor typographical nits but (intentionally) no substantive content 574 changes. 576 A.2. Since draft-young-md-query-00 578 Split into two documents: this one is as agnostic as possible around 579 questions such as metadata format and higher level protocol use 580 cases, a new layered document describes the detailed requirements for 581 SAML support. 583 Rewrite Section 3.2.1 to clarify construction of the request URL and 584 its relationship to the base URL. 586 Added Section 2.1 to clarify that the transport protocol underlying 587 HTTP may be either TCP or SSL/TLS. 589 Clarify position on HTTP versions (Section 2.2) which may be used to 590 underly this protocol. 592 Added Change Log modelled on draft-ietf-httpbis-http2. 594 Added a reference to [STD68]. Use ABNF to describe request syntax. 595 Replace transformed identifier concept with extended identifiers 596 (this also resulted in the removal of any discussion of specific 597 transformed identifier formats). Add grammar to distinguish basic 598 from extended identifiers. 600 Changed the required response when the result can not be validly 601 expressed in the requested format from 500 to 406. 603 Removed the '+' operator and all references to multiple identifiers 604 in queries. If more complex queries are required, these will be 605 reintroduced at a different path under the base URL. 607 Added a section describing Protocol Extension Points. 609 A.3. Since draft-young-md-query-01 611 Added REFEDS RFC stream boilerplate. 613 Tidied up some normative language. 615 A.4. Since draft-young-md-query-02 617 Introduced a normative reference to [STD66]. 619 Reworked the definition of the base URL so that a non-empty path 620 ending with '/' is required. This allows the definition of request 621 URLs to be simplified. 623 Clarified the definition of the base URL to exclude a query 624 component; corrected the terminology for the fragment identifier 625 component. 627 Added the definition for the query for all entities in Section 3.2.2. 629 Corrected an example in Section 3.2.4 to include the required double 630 quotes in the value of an ETag header. Added text to clarify the 631 base URL and identifier being used in the example. 633 Simplified the definition of identifiers, so that any non-empty 634 identifier is accepted and no semantics are defined for particular 635 structures. Extended syntaxes such as the {sha1} notation for 636 transformed identifiers are now left to profiles. 638 Remove incidental references to SSL. 640 Remove status code 501 ("not implemented") as it is no longer 641 referenced. 643 A.5. Since draft-young-md-query-03 645 Correct a typo in the identifier grammar. 647 A.6. Since draft-young-md-query-04 649 Updated to rely on the new definition of HTTP/1.1 in [RFC7230] et 650 seq. instead of RFC 2616. 652 Corrected Section 3.2.3 to indicate that the request contains an 653 Accept header, not a Content-Type header. 655 Added an Editorial Note to help direct readers back to the 656 discussion. 658 A.7. Since draft-young-md-query-05 660 Remove unnecessary percent-encoding of a ':' character in the example 661 in Section 3.2.4. 663 Removed use of the ambiguous term "URL-encoded" in Section 3.2.1. 664 Instead, indicate that the encoding must correspond to the rules for 665 encoding a URL path segment specifically, and call out some of the 666 more important implications arising from that. Added a new example 667 illustrating these implications. 669 Updated the description of conditional retrieval in Section 4.1 to 670 make the use of a 304 (Not Modified) status code a normative but non- 671 mandatory obligation on the responder, not simply a description of 672 what the requester will receive. 674 A.8. Since draft-young-md-query-06 676 No substantive changes. 678 A.9. Since draft-young-md-query-07 680 No substantive changes. 682 A.10. Since draft-young-md-query-08 684 Modernise normative language to include [RFC8174]. 686 Reference [RFC7617] instead of the Internet-Draft. 688 Improved references to RFCs. 690 A.11. Since draft-young-md-query-09 692 No substantive changes. 694 A.12. Since draft-young-md-query-10 696 No substantive changes. 698 A.13. Since draft-young-md-query-11 700 No substantive changes. 702 A.14. Since draft-young-md-query-12 704 No substantive changes. 706 A.15. Since draft-young-md-query-13 708 No substantive changes. 710 A.16. Since draft-young-md-query-14 712 No substantive changes. 714 A.17. Since draft-young-md-query-15 716 No substantive changes. 718 Author's Address 720 Ian A. Young (editor) 721 Independent 723 Email: ian@iay.org.uk