idnits 2.17.1 draft-inadarei-api-health-check-06.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * componentName: (optional) human-readable name for the component. MUST not contain a colon, in the name, since colon is used as a separator. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * measurementName: (optional) name of the measurement type (a data point type) that the status is reported for. MUST not contain a colon, in the name, since colon is used as a separator. The observation's name can be one of: -- The document date (16 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6838' is defined on line 650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group I. Nadareishvili 3 Internet-Draft 16 October 2021 4 Intended status: Informational 5 Expires: 19 April 2022 7 Health Check Response Format for HTTP APIs 8 draft-inadarei-api-health-check-06 10 Abstract 12 This document proposes a service health check response format for 13 HTTP APIs. 15 Note to Readers 17 *RFC EDITOR: please remove this section before publication* 19 The issues list for this draft can be found at 20 https://github.com/inadarei/rfc-healthcheck/issues 21 (https://github.com/inadarei/rfc-healthcheck/issues). 23 The most recent draft is at https://inadarei.github.io/rfc- 24 healthcheck/ (https://inadarei.github.io/rfc-healthcheck/). 26 Recent changes are listed at https://github.com/inadarei/rfc- 27 healthcheck/commits/master (https://github.com/inadarei/rfc- 28 healthcheck/commits/master). 30 See also the draft's current status in the IETF datatracker, at 31 https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/ 32 (https://datatracker.ietf.org/doc/draft-inadarei-api-health-check/). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 19 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 68 3. API Health Response . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. status . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. version . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.3. releaseId . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.4. notes . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.5. output . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.6. checks . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.7. links . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.8. serviceId . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.9. description . . . . . . . . . . . . . . . . . . . . . . . 5 78 4. The Checks Object . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. componentId . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. componentType . . . . . . . . . . . . . . . . . . . . . . 7 81 4.3. observedValue . . . . . . . . . . . . . . . . . . . . . . 7 82 4.4. observedUnit . . . . . . . . . . . . . . . . . . . . . . 7 83 4.5. status . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.6. affectedEndpoints . . . . . . . . . . . . . . . . . . . . 8 85 4.7. time . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.8. output . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4.9. links . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 4.10. Additional Keys . . . . . . . . . . . . . . . . . . . . . 9 89 5. Example Output . . . . . . . . . . . . . . . . . . . . . . . 9 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 93 9. Creating and Serving Health Responses . . . . . . . . . . . . 13 94 10. Consuming Health Check Responses . . . . . . . . . . . . . . 13 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 97 11.2. Informative References . . . . . . . . . . . . . . . . . 14 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 100 1. Introduction 102 The vast majority of modern APIs driving data to web and mobile 103 applications use HTTP [RFC7230] as their protocol. The health and 104 uptime of these APIs determine availability of the applications 105 themselves. In distributed systems built with a number of APIs, 106 understanding the health status of the APIs and making corresponding 107 decisions, for caching, failover or circuit-breaking, are essential 108 to the ability of providing highly-available solutions. 110 There exists a wide variety of operational software that relies on 111 the ability to read health check response of APIs. However, there is 112 currently no standard for the health check output response, so most 113 applications either rely on the basic level of information included 114 in HTTP status codes [RFC7231] or use task-specific formats. 116 Usage of task-specific or application-specific formats creates 117 significant challenges, disallowing any meaningful interoperability 118 across different implementations and between different tooling. 120 Standardizing a format for health checks can provide any of a number 121 of benefits, including: 123 * Flexible deployment - since operational tooling and API clients 124 can rely on rich, uniform format, they can be safely combined and 125 substituted as needed. 127 * Evolvability - new APIs, conforming to the standard, can safely be 128 introduced in any environment and ecosystem that also conforms to 129 the same standard, without costly coordination and testing 130 requirements. 132 This document defines a "health check" format using the JSON format 133 [RFC8259] for APIs to use as a standard point for the health 134 information they offer. Having a well-defined format for this 135 purpose promotes good practice and tooling. 137 2. Notational Conventions 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. API Health Response 145 Health Check Response Format for HTTP APIs uses the JSON format 146 described in [RFC8259] and has the media type "application/ 147 health+json". 149 Its content consists of a single mandatory root field ("status") and 150 several optional fields: 152 3.1. status 154 status: (required) indicates whether the service status is acceptable 155 or not. API publishers SHOULD use following values for the field: 157 * "pass": healthy (acceptable aliases: "ok" to support Node's 158 Terminus and "up" for Java's SpringBoot), 160 * "fail": unhealthy (acceptable aliases: "error" to support Node's 161 Terminus and "down" for Java's SpringBoot), and 163 * "warn": healthy, with some concerns. 165 The value of the status field is case-insensitive and is tightly 166 related with the HTTP response code returned by the health endpoint. 167 For "pass" status, HTTP response code in the 2xx-3xx range MUST be 168 used. For "fail" status, HTTP response code in the 4xx-5xx range 169 MUST be used. In case of the "warn" status, endpoints MUST return 170 HTTP status in the 2xx-3xx range, and additional information SHOULD 171 be provided, utilizing optional fields of the response. 173 A health endpoint is only meaningful in the context of the component 174 it indicates the health of. It has no other meaning or purpose. As 175 such, its health is a conduit to the health of the component. 176 Clients SHOULD assume that the HTTP response code returned by the 177 health endpoint is applicable to the entire component (e.g. a larger 178 API or a microservice). This is compatible with the behavior that 179 current infrastructural tooling expects: load-balancers, service 180 discoveries and others, utilizing health-checks. 182 3.2. version 184 version: (optional) public version of the service. 186 3.3. releaseId 188 releaseId: (optional) in well-designed APIs, backwards-compatible 189 changes in the service should not update a version number. APIs 190 usually change their version number as infrequently as possible, to 191 preserve stable interface. However, implementation of an API may 192 change much more frequently, which leads to the importance of having 193 separate "release number" or "releaseId" that is different from the 194 public version of the API. 196 3.4. notes 198 notes: (optional) array of notes relevant to current state of health 200 3.5. output 202 output: (optional) raw error output, in case of "fail" or "warn" 203 states. This field SHOULD be omitted for "pass" state. 205 3.6. checks 207 checks (optional) is an object that provides detailed health statuses 208 of additional downstream systems and endpoints which can affect the 209 overall health of the main API. Please refer to the "The Checks 210 Object" section for more information. 212 3.7. links 214 links (optional) is an object containing link relations and URIs 215 [RFC3986] for external links that MAY contain more information about 216 the health of the endpoint. All values of this object SHALL be URIs. 217 Keys MAY also be URIs. Per web-linking standards [RFC8288] a link 218 relationship SHOULD either be a common/registered one or be indicated 219 as a URI, to avoid name clashes. If a "self" link is provided, it 220 MAY be used by clients to check health via HTTP response code, as 221 mentioned above. 223 3.8. serviceId 225 serviceId (optional) is a unique identifier of the service, in the 226 application scope. 228 3.9. description 230 description (optional) is a human-friendly description of the 231 service. 233 4. The Checks Object 235 The "checks" object MAY have a number of unique keys, one for each 236 logical downstream dependency or sub-component. Since each sub- 237 component may be backed by several nodes with varying health 238 statuses, these keys point to arrays of objects. In case of a 239 single-node sub-component (or if presence of nodes is not relevant), 240 a single-element array SHOULD be used as the value, for consistency. 242 The key identifying an element in the object SHOULD be a unique 243 string within the details section. It MAY have two parts: 244 "{componentName}:{measurementName}", in which case the meaning of the 245 parts SHOULD be as follows: 247 * componentName: (optional) human-readable name for the component. 248 MUST not contain a colon, in the name, since colon is used as a 249 separator. 251 * measurementName: (optional) name of the measurement type (a data 252 point type) that the status is reported for. MUST not contain a 253 colon, in the name, since colon is used as a separator. The 254 observation's name can be one of: 256 - A pre-defined value from this spec. Pre-defined values 257 include: 259 o utilization 261 o responseTime 263 o connections 265 o uptime 267 - A common and standard term from a well-known source such as 268 schema.org, IANA or microformats. 270 - A URI that indicates extra semantics and processing rules that 271 MAY be provided by a resource at the other end of the URI. 272 URIs do not have to be dereferenceable, however. They are just 273 a namespace, and the meaning of a namespace CAN be provided by 274 any convenient means (e.g. publishing an RFC, Open API Spec 275 document or a nicely printed book). 277 On the value side of the equation, each "component details" object in 278 the array SHOULD have at least one key, and MAY have any or none of 279 the following object keys: 281 4.1. componentId 283 componentId: (optional) is a unique identifier of an instance of a 284 specific sub-component/dependency of a service. Multiple objects 285 with the same componentID MAY appear in the details, if they are from 286 different nodes. 288 4.2. componentType 290 componentType: (optional) SHOULD be present if componentName is 291 present. It's a type of the component and could be one of: 293 * Pre-defined value from this spec. Pre-defined values include: 295 - component 297 - datastore 299 - system 301 * A common and standard term from a well-known source such as 302 schema.org, IANA or microformats. 304 * A URI that indicates extra semantics and processing rules that MAY 305 be provided by a resource at the other end of the URI. URIs do 306 not have to be dereferenceable, however. They are just a 307 namespace, and the meaning of a namespace CAN be provided by any 308 convenient means (e.g. publishing an RFC, Swagger document or a 309 nicely printed book). 311 4.3. observedValue 313 observedValue: (optional) could be any valid JSON value, such as: 314 string, number, object, array or literal. 316 4.4. observedUnit 318 observedUnit (optional) SHOULD be present if observedValue is 319 present. Clarifies the unit of measurement in which observedUnit is 320 reported, e.g. for a time-based value it is important to know whether 321 the time is reported in seconds, minutes, hours or something else. 322 To make sure unit is denoted by a well-understood name or an 323 abbreviation, it SHOULD be one of: 325 * A common and standard term from a well-known source such as 326 schema.org, IANA, microformats, or a standards document such as 327 [RFC3339]. 329 * A URI that indicates extra semantics and processing rules that MAY 330 be provided by a resource at the other end of the URI. URIs do 331 not have to be dereferenceable, however. They are just a 332 namespace, and the meaning of a namespace CAN be provided by any 333 convenient means (e.g. publishing an RFC, Swagger document or a 334 nicely printed book). 336 4.5. status 338 status (optional) has the exact same meaning as the top-level 339 "output" element, but for the sub-component/downstream dependency 340 represented by the details object. 342 4.6. affectedEndpoints 344 affectedEndpoints (optional) is a JSON array containing URI Templates 345 as defined by [RFC6570]. This field SHOULD be omitted if the 346 "status" field is present and has value equal to "pass". A typical 347 API has many URI endpoints. Most of the time we are interested in 348 the overall health of the API, without diving into details. That 349 said, sometimes operational and resilience middleware needs to know 350 more details about the health of the API (which is why "checks" 351 property provides details). In such cases, we often need to indicate 352 which particular endpoints are affected by a particular check's 353 troubles vs. other endpoints that may be fine. 355 4.7. time 357 time (optional) is the date-time, in ISO8601 format, at which the 358 reading of the observedValue was recorded. This assumes that the 359 value can be cached and the reading typically doesn't happen in real 360 time, for performance and scalability purposes. 362 4.8. output 364 output (optional) has the exact same meaning as the top-level 365 "output" element, but for the sub-component/downstream dependency 366 represented by the details object. As is the case for the top-level 367 element, this field SHOULD be omitted for "pass" state of a 368 downstream dependency. 370 4.9. links 372 links (optional) has the exact same meaning as the top-level "output" 373 element, but for the sub-component/downstream dependency represented 374 by the details object. 376 4.10. Additional Keys 378 In addition to the above keys, additional user-defined keys MAY be 379 included in the 'component details' object. Implementations MAY 380 ignore any keys that are not part of the list of standard keys above. 382 5. Example Output 384 GET /health HTTP/1.1 385 Host: example.org 386 Accept: application/health+json 388 HTTP/1.1 200 OK 389 Content-Type: application/health+json 390 Cache-Control: max-age=3600 391 Connection: close 393 { 394 "status": "pass", 395 "version": "1", 396 "releaseId": "1.2.2", 397 "notes": [""], 398 "output": "", 399 "serviceId": "f03e522f-1f44-4062-9b55-9587f91c9c41", 400 "description": "health of authz service", 401 "checks": { 402 "cassandra:responseTime": [ 403 { 404 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 405 "componentType": "datastore", 406 "observedValue": 250, 407 "observedUnit": "ms", 408 "status": "pass", 409 "affectedEndpoints" : [ 410 "/users/{userId}", 411 "/customers/{customerId}/status", 412 "/shopping/{anything}" 413 ], 414 "time": "2018-01-17T03:36:48Z", 415 "output": "" 416 } 417 ], 418 "cassandra:connections": [ 419 { 420 "componentId": "dfd6cf2b-1b6e-4412-a0b8-f6f7797a60d2", 421 "componentType": "datastore", 422 "observedValue": 75, 423 "status": "warn", 424 "time": "2018-01-17T03:36:48Z", 425 "output": "", 426 "links": { 427 "self": "http://api.example.com/dbnode/dfd6cf2b/health" 428 } 429 } 430 ], 431 "uptime": [ 432 { 433 "componentType": "system", 434 "observedValue": 1209600.245, 435 "observedUnit": "s", 436 "status": "pass", 437 "time": "2018-01-17T03:36:48Z" 438 } 439 ], 440 "cpu:utilization": [ 441 { 442 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 443 "node": 1, 444 "componentType": "system", 445 "observedValue": 85, 446 "observedUnit": "percent", 447 "status": "warn", 448 "time": "2018-01-17T03:36:48Z", 449 "output": "" 450 }, 451 { 452 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 453 "node": 2, 454 "componentType": "system", 455 "observedValue": 85, 456 "observedUnit": "percent", 457 "status": "warn", 458 "time": "2018-01-17T03:36:48Z", 459 "output": "" 460 } 461 ], 462 "memory:utilization": [ 463 { 464 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 465 "node": 1, 466 "componentType": "system", 467 "observedValue": 8.5, 468 "observedUnit": "GiB", 469 "status": "warn", 470 "time": "2018-01-17T03:36:48Z", 471 "output": "" 473 }, 474 { 475 "componentId": "6fd416e0-8920-410f-9c7b-c479000f7227", 476 "node": 2, 477 "componentType": "system", 478 "observedValue": 5500, 479 "observedUnit": "MiB", 480 "status": "pass", 481 "time": "2018-01-17T03:36:48Z", 482 "output": "" 483 } 484 ] 485 }, 486 "links": { 487 "about": "http://api.example.com/about/authz", 488 "http://api.x.io/rel/thresholds": 489 "http://api.x.io/about/authz/thresholds" 490 } 491 } 493 6. Security Considerations 495 Clients need to exercise care when reporting health information. 496 Malicious actors could use this information for orchestrating 497 attacks. In some cases, the health check endpoints may need to be 498 authenticated and institute role-based access control. 500 7. IANA Considerations 502 The media type for health check response is application/health+json. 504 * Media type name: application 506 * Media subtype name: health+json 508 * Required parameters: n/a 510 * Optional parameters: n/a 512 * Encoding considerations: binary 514 * Security considerations: Health+JSON shares security issues common 515 to all JSON content types. See RFC 8259 Section #12 for 516 additional information. 518 Health+JSON allows utilization of Uniform Resource Identifiers 519 (URIs) and as such shares security issues common to URI usage. 520 See RFC 3986 Section #7 for additional information. 522 Since health+json can carry wide variety of data, some data may 523 require privacy or integrity services. This specification does 524 not prescribe any specific solution and assumes that concrete 525 implementations will utilize common, trusted approaches such as 526 TLS/HTTPS, OAuth2 etc. 528 * Interoperability considerations: None 530 * Published specification: this RFC draft 532 * Applications which use this media: Various 534 * Fragment identifier considerations: Health+JSON follows RFC6901 535 for implementing URI Fragment Identification standard to JSON 536 content types. 538 * Restrictions on usage: None 540 * Additional information: 542 1. Deprecated alias names for this type: n/a 544 2. Magic number(s): n/a 546 3. File extension(s): .json 548 4. Macintosh file type code: TEXT 550 5. Object Identifiers: n/a 552 * General Comments: 554 * Person to contact for further information: 556 1. Name: Irakli Nadareishvili 558 2. Email: irakli@gmail.com 560 * Intended usage: Common 562 * Author/Change controller: Irakli Nadareishvili 564 8. Acknowledgements 566 Thanks to Mike Amundsen, Erik Wilde, Justin Bachorik and Randall 567 Randall for their suggestions and feedback. And to Mark Nottingham 568 for blueprint for authoring RFCs easily. 570 9. Creating and Serving Health Responses 572 When making an health check endpoint available, there are a few 573 things to keep in mind: 575 * A health response endpoint is best located at a memorable and 576 commonly-used URI, such as "health" because it will help self- 577 discoverability by clients. 579 * Health check responses can be personalized. For example, you 580 could advertise different URIs, and/or different kinds of link 581 relations, to afford different clients access to additional health 582 check information. 584 * Health check responses SHOULD be assigned a freshness lifetime 585 (e.g., "Cache-Control: max-age=3600") so that clients can 586 determine how long they could cache them, to avoid overly frequent 587 fetching and unintended DDOS-ing of the service. Any method of 588 cache lifetime negotiation provided by HTTP spec is acceptable 589 (e.g. ETags are just fine). 591 * Custom link relation types, as well as the URIs for variables, 592 SHOULD lead to documentation for those constructs. 594 10. Consuming Health Check Responses 596 Clients might use health check responses in a variety of ways. 598 Note that the health check response is a "living" document; links 599 from the health check response MUST NOT be assumed to be valid beyond 600 the freshness lifetime of the health check response, as per HTTP's 601 caching model [RFC7234]. 603 As a result, clients ought to cache the health check response (as per 604 [RFC7234]), to avoid fetching it before every interaction (which 605 would otherwise be required). 607 Likewise, a client encountering a 404 (Not Found) on a link is 608 encouraged to obtain a fresh copy of the health check response, to 609 assure that it is up-to-date. 611 11. References 613 11.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 621 Resource Identifier (URI): Generic Syntax", STD 66, 622 RFC 3986, DOI 10.17487/RFC3986, January 2005, 623 . 625 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 626 and D. Orchard, "URI Template", RFC 6570, 627 DOI 10.17487/RFC6570, March 2012, 628 . 630 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 631 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 632 RFC 7234, DOI 10.17487/RFC7234, June 2014, 633 . 635 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 636 Interchange Format", STD 90, RFC 8259, 637 DOI 10.17487/RFC8259, December 2017, 638 . 640 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 641 DOI 10.17487/RFC8288, October 2017, 642 . 644 11.2. Informative References 646 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 647 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 648 . 650 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 651 Specifications and Registration Procedures", BCP 13, 652 RFC 6838, DOI 10.17487/RFC6838, January 2013, 653 . 655 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 656 Protocol (HTTP/1.1): Message Syntax and Routing", 657 RFC 7230, DOI 10.17487/RFC7230, June 2014, 658 . 660 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 661 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 662 DOI 10.17487/RFC7231, June 2014, 663 . 665 Author's Address 667 Irakli Nadareishvili 668 114 5th Avenue 669 New York, 670 United States of America 672 Email: irakli@gmail.com 673 URI: http://www.freshblurbs.com