ver 4 started

inadarei · May 10, 2019 · 80ece69 · 80ece69
1 parent dbcb9e9
commit 80ece69
Show file tree

Hide file tree

Showing 6 changed files with 88 additions and 88 deletions.
diff --git a/draft-inadarei-api-health-check-03.html b/draft-inadarei-api-health-check-03.html
@@ -413,7 +413,7 @@
 
   <meta name="dct.creator" content="Nadareishvili, I." />
   <meta name="dct.identifier" content="urn:ietf:id:draft-inadarei-api-health-check-03" />
-  <meta name="dct.issued" scheme="ISO8601" content="2018-31" />
+  <meta name="dct.issued" scheme="ISO8601" content="2019-09" />
   <meta name="dct.abstract" content="This document proposes a service health check response format for HTTP APIs." />
   <meta name="description" content="This document proposes a service health check response format for HTTP APIs." />
 
@@ -430,14 +430,14 @@
 </tr>
 <tr>
 <td class="left">Internet-Draft</td>
-<td class="right">March 31, 2018</td>
+<td class="right">May 9, 2019</td>
 </tr>
 <tr>
 <td class="left">Intended status: Informational</td>
 <td class="right"></td>
 </tr>
 <tr>
-<td class="left">Expires: October 2, 2019</td>
+<td class="left">Expires: November 10, 2019</td>
 <td class="right"></td>
 </tr>
 
@@ -460,9 +460,9 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on October 2, 2019.</p>
+<p>This Internet-Draft will expire on November 10, 2019.</p>
 <h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
-<p>Copyright (c) 2018 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
+<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>
 
 

diff --git a/draft-inadarei-api-health-check-03.txt b/draft-inadarei-api-health-check-03.txt
@@ -3,9 +3,9 @@
 
 
 Network Working Group                                   I. Nadareishvili
-Internet-Draft                                            March 31, 2018
+Internet-Draft                                               May 9, 2019
 Intended status: Informational
-Expires: October 2, 2019
+Expires: November 10, 2019
 
 
                Health Check Response Format for HTTP APIs
@@ -48,19 +48,19 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on October 2, 2019.
+   This Internet-Draft will expire on November 10, 2019.
 
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 1]
+Nadareishvili           Expires November 10, 2019               [Page 1]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
 Copyright Notice
 
-   Copyright (c) 2018 IETF Trust and the persons identified as the
+   Copyright (c) 2019 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
@@ -109,9 +109,9 @@ Table of Contents
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 2]
+Nadareishvili           Expires November 10, 2019               [Page 2]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
      11.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  14
@@ -165,9 +165,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 3]
+Nadareishvili           Expires November 10, 2019               [Page 3]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
 3.  API Health Response
@@ -221,9 +221,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 4]
+Nadareishvili           Expires November 10, 2019               [Page 4]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    preserve stable interface.  However, implementation of an API may
@@ -277,9 +277,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 5]
+Nadareishvili           Expires November 10, 2019               [Page 5]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    single-node sub-component (or if presence of nodes is not relevant),
@@ -333,9 +333,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 6]
+Nadareishvili           Expires November 10, 2019               [Page 6]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
 4.2.  componentType
@@ -389,9 +389,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 7]
+Nadareishvili           Expires November 10, 2019               [Page 7]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
 4.5.  status
@@ -445,9 +445,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 8]
+Nadareishvili           Expires November 10, 2019               [Page 8]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    {
@@ -501,9 +501,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019                [Page 9]
+Nadareishvili           Expires November 10, 2019               [Page 9]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
          {
@@ -557,9 +557,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 10]
+Nadareishvili           Expires November 10, 2019              [Page 10]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
      }
@@ -613,9 +613,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 11]
+Nadareishvili           Expires November 10, 2019              [Page 11]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    o  Restrictions on usage: None
@@ -669,9 +669,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 12]
+Nadareishvili           Expires November 10, 2019              [Page 12]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
       determine how long they could cache them, to avoid overly frequent
@@ -725,9 +725,9 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 13]
+Nadareishvili           Expires November 10, 2019              [Page 13]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
@@ -781,9 +781,9 @@ Author's Address
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 14]
+Nadareishvili           Expires November 10, 2019              [Page 14]
 
-Internet-Draft Health Check Response Format for HTTP APIs     March 2018
+Internet-Draft Health Check Response Format for HTTP APIs       May 2019
 
 
    Irakli Nadareishvili
@@ -837,4 +837,4 @@ Internet-Draft Health Check Response Format for HTTP APIs     March 2018
 
 
 
-Nadareishvili            Expires October 2, 2019               [Page 15]
+Nadareishvili           Expires November 10, 2019              [Page 15]
diff --git a/draft-inadarei-api-health-check-03.xml b/draft-inadarei-api-health-check-03.xml
@@ -32,7 +32,7 @@
       </address>
     </author>
 
-    <date year="2018"/>
+    <date year="2019"/>
 
     <area>General</area>
 

diff --git a/draft.md b/draft.md
@@ -1,8 +1,8 @@
 ---
 title: Health Check Response Format for HTTP APIs
 abbrev:
-docname: draft-inadarei-api-health-check-03
-date: 2018
+docname: draft-inadarei-api-health-check-04
+date: 2019
 category: info
 
 ipr: trust200902
@@ -19,7 +19,7 @@ author:
     name: Irakli Nadareishvili
     street: 114 5th Avenue
     city: New York
-    country: United States
+    country: United States of America
     email: [email protected]
     uri: http://www.freshblurbs.com
 
@@ -105,7 +105,7 @@ Health Check Response Format for HTTP APIs uses the JSON format described in
 Its content consists of a single mandatory root field ("status") and several
 optional fields:
 
-## status 
+## status
 
 status: (required) indicates whether the service status is acceptable or not.
 API publishers SHOULD use following values for the field:
@@ -132,7 +132,7 @@ API publishers SHOULD use following values for the field:
   with the behavior that current infrastructural tooling expects:
   load-balancers, service discoveries and others, utilizing health-checks.
 
-## version 
+## version
 
 version: (optional) public version of the service.
 
@@ -193,7 +193,7 @@ The key identifying an element in the object SHOULD be a unique string within
 the details section. It MAY have two parts: "{componentName}:{measurementName}",
 in which case the meaning of the parts SHOULD be as follows:
 
-* componentName: (optional) human-readable name for the component. MUST not 
+* componentName: (optional) human-readable name for the component. MUST not
   contain a colon, in the name, since colon is used as a separator.
 * 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
@@ -209,7 +209,7 @@ in which case the meaning of the parts SHOULD be as follows:
     provided by a resource at the other end of the URI. URIs do not have to be
     dereferenceable, however. They are just a namespace, and the meaning of a
     namespace CAN be provided by any convenient means (e.g. publishing an RFC,
-    Swagger document or a nicely printed book).
+    Open API Spec document or a nicely printed book).
 
 On the value side of the equation, each "component details" object in the array
 MAY have one of the following object keys:
@@ -235,8 +235,8 @@ a type of the component and could be one of:
     provided by a resource at the other end of the URI. URIs do not have to be
     dereferenceable, however. They are just a namespace, and the meaning of a
     namespace CAN be provided by any convenient means (e.g. publishing an RFC,
-    Swagger document or a nicely printed book).   
-    
+    Swagger document or a nicely printed book).
+
 ## observedValue
 
 observedValue: (optional) could be any valid JSON value, such as: string, number,
@@ -258,7 +258,7 @@ or an abbreviation, it SHOULD be one of:
     namespace CAN be provided by any convenient means (e.g. publishing an RFC,
     Swagger document or a nicely printed book).
 
-## status 
+## status
 
 status (optional) has the exact same meaning as the top-level "output"
 element, but for the sub-component/downstream dependency represented
@@ -281,7 +281,7 @@ observedValue was recorded. This assumes that the value can be cached and the
 reading typically doesn't happen in real time, for performance and scalability
 purposes.
 
-## output 
+## output
 
 output (optional) has the exact same meaning as the top-level "output"
 element, but for the sub-component/downstream dependency represented

diff --git a/index.html b/index.html
@@ -413,7 +413,7 @@
 
   <meta name="dct.creator" content="Nadareishvili, I." />
   <meta name="dct.identifier" content="urn:ietf:id:draft-inadarei-api-health-check-03" />
-  <meta name="dct.issued" scheme="ISO8601" content="2018-31" />
+  <meta name="dct.issued" scheme="ISO8601" content="2019-09" />
   <meta name="dct.abstract" content="This document proposes a service health check response format for HTTP APIs." />
   <meta name="description" content="This document proposes a service health check response format for HTTP APIs." />
 
@@ -430,14 +430,14 @@
 </tr>
 <tr>
 <td class="left">Internet-Draft</td>
-<td class="right">March 31, 2018</td>
+<td class="right">May 9, 2019</td>
 </tr>
 <tr>
 <td class="left">Intended status: Informational</td>
 <td class="right"></td>
 </tr>
 <tr>
-<td class="left">Expires: October 2, 2019</td>
+<td class="left">Expires: November 10, 2019</td>
 <td class="right"></td>
 </tr>
 
@@ -460,9 +460,9 @@ <h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF).  Note that other groups may also distribute working documents as Internet-Drafts.  The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.</p>
 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.  It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."</p>
-<p>This Internet-Draft will expire on October 2, 2019.</p>
+<p>This Internet-Draft will expire on November 10, 2019.</p>
 <h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
-<p>Copyright (c) 2018 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
+<p>Copyright (c) 2019 IETF Trust and the persons identified as the document authors.  All rights reserved.</p>
 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document.  Please review these documents carefully, as they describe your rights and restrictions with respect to this document.  Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p>