From 31b158ac57fe6ffa4531c87c0dd0268d361392b0 Mon Sep 17 00:00:00 2001 From: Irakli N Date: Sat, 24 Mar 2018 18:10:00 -0400 Subject: [PATCH] rebuilt generated spec files --- draft-inadarei-api-health-check-01.html | 34 ++- draft-inadarei-api-health-check-01.txt | 152 +++++++---- draft-inadarei-api-health-check-01.xml | 339 ++++++++++++------------ index.html | 34 ++- index.txt | 152 +++++++---- 5 files changed, 413 insertions(+), 298 deletions(-) diff --git a/draft-inadarei-api-health-check-01.html b/draft-inadarei-api-health-check-01.html index c9242d7..92555e2 100644 --- a/draft-inadarei-api-health-check-01.html +++ b/draft-inadarei-api-health-check-01.html @@ -689,31 +689,37 @@

7. IANA Considerations

The media type for health check response is application/health+json.

-

Media type name: application Media subtype name: health+json Required parameters: n/a Optional parameters: n/a Encoding considerations: binary Security considerations: Health+JSON shares security issues common to all JSON content types. See RFC 8259 Section #12 for additional information.

-

Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such shares security issues common to URI usage. See RFC 3986 Section #7 for additional information.

-

Since Hyper+JSON can carry wide variety of data, some data may require privacy or integrity services. This specification does not prescribe any specific solution and assumes that concrete implementations will utilize common, trusted approaches such as TLS/HTTPS, OAuth2 etc.

-

Interoperability considerations: None Published specification: this RFC draft Applications which use this media: Various

-

Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types.

-

Restrictions on usage: None

-

Additional information:

-
    +

    8. Acknowledgements

    diff --git a/draft-inadarei-api-health-check-01.txt b/draft-inadarei-api-health-check-01.txt index 6d1f7b4..92763ad 100644 --- a/draft-inadarei-api-health-check-01.txt +++ b/draft-inadarei-api-health-check-01.txt @@ -473,31 +473,31 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 The media type for health check response is application/health+json. - Media type name: application Media subtype name: health+json Required - parameters: n/a Optional parameters: n/a Encoding considerations: - binary Security considerations: Health+JSON shares security issues - common to all JSON content types. See RFC 8259 Section #12 for - additional information. + o Media type name: application - Health+JSON allows utilization of Uniform Resource Identifiers (URIs) - and as such shares security issues common to URI usage. See RFC 3986 - Section #7 for additional information. + o Media subtype name: health+json - Since Hyper+JSON can carry wide variety of data, some data may - require privacy or integrity services. This specification does not - prescribe any specific solution and assumes that concrete - implementations will utilize common, trusted approaches such as TLS/ - HTTPS, OAuth2 etc. + o Required parameters: n/a - Interoperability considerations: None Published specification: this - RFC draft Applications which use this media: Various + o Optional parameters: n/a - Fragment identifier considerations: Health+JSON follows RFC6901 for - implementing URI Fragment Identification standard to JSON content - types. + o Encoding considerations: binary - Restrictions on usage: None + o Security considerations: Health+JSON shares security issues common + to all JSON content types. See RFC 8259 Section #12 for + additional information. + Health+JSON allows utilization of Uniform Resource Identifiers + (URIs) and as such shares security issues common to URI usage. + See RFC 3986 Section #7 for additional information. + + Since Hyper+JSON can carry wide variety of data, some data may + require privacy or integrity services. This specification does + not prescribe any specific solution and assumes that concrete + implementations will utilize common, trusted approaches such as + TLS/HTTPS, OAuth2 etc. + + o Interoperability considerations: None @@ -506,27 +506,39 @@ Nadareishvili Expires September 25, 2018 [Page 9] Internet-Draft Health Check Response Format for HTTP APIs March 2018 - Additional information: + o Published specification: this RFC draft + + o Applications which use this media: Various + + o Fragment identifier considerations: Health+JSON follows RFC6901 + for implementing URI Fragment Identification standard to JSON + content types. + + o Restrictions on usage: None + + o Additional information: - 1. Deprecated alias names for this type: n/a + 1. Deprecated alias names for this type: n/a - 2. Magic number(s): n/a + 2. Magic number(s): n/a - 3. File extension(s): .json + 3. File extension(s): .json - 4. Macintosh file type code: TEXT + 4. Macintosh file type code: TEXT - 5. Object Identifiers: n/a + 5. Object Identifiers: n/a - General Comments: + o General Comments: - Person to contact for further information: + o Person to contact for further information: - 1. Name: Irakli Nadareishvili + 1. Name: Irakli Nadareishvili - 2. Email: irakli@gmail.com + 2. Email: irakli@gmail.com - Intended usage: Common Author/Change controller: Irakli Nadareishvili + o Intended usage: Common + + o Author/Change controller: Irakli Nadareishvili 8. Acknowledgements @@ -543,6 +555,13 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 commonly-used URI, such as "health" because it will help self- discoverability by clients. + + +Nadareishvili Expires September 25, 2018 [Page 10] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + o Health check responses can be personalized. For example, you could advertise different URIs, and/or different kinds of link relations, to afford different clients access to additional health @@ -553,15 +572,6 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 determine how long they could cache them, to avoid overly frequent fetching and unintended DDOS-ing of the service. - - - - -Nadareishvili Expires September 25, 2018 [Page 10] - -Internet-Draft Health Check Response Format for HTTP APIs March 2018 - - o Custom link relation types, as well as the URIs for variables, should lead to documentation for those constructs. @@ -600,6 +610,14 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 DOI 10.17487/RFC5988, October 2010, . + + + +Nadareishvili Expires September 25, 2018 [Page 11] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, @@ -610,14 +628,6 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 DOI 10.17487/RFC8259, December 2017, . - - - -Nadareishvili Expires September 25, 2018 [Page 11] - -Internet-Draft Health Check Response Format for HTTP APIs March 2018 - - 11.2. Informative References [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: @@ -651,6 +661,19 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 Author's Address + + + + + + + + +Nadareishvili Expires September 25, 2018 [Page 12] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + Irakli Nadareishvili 114 5th Avenue New York @@ -669,4 +692,37 @@ Author's Address -Nadareishvili Expires September 25, 2018 [Page 12] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadareishvili Expires September 25, 2018 [Page 13] diff --git a/draft-inadarei-api-health-check-01.xml b/draft-inadarei-api-health-check-01.xml index f967863..900a4a6 100644 --- a/draft-inadarei-api-health-check-01.xml +++ b/draft-inadarei-api-health-check-01.xml @@ -372,54 +372,45 @@ access control. The media type for health check response is application/health+json. -Media type name: application -Media subtype name: health+json -Required parameters: n/a -Optional parameters: n/a -Encoding considerations: binary -Security considerations: Health+JSON shares security issues common to all JSON -content types. See RFC 8259 Section #12 for additional information. - -Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such -shares security issues common to URI usage. See RFC 3986 Section #7 -for additional information. - -Since Hyper+JSON can carry wide variety of data, some data may require privacy -or integrity services. This specification does not prescribe any specific -solution and assumes that concrete implementations will utilize common, trusted -approaches such as TLS/HTTPS, OAuth2 etc. - -Interoperability considerations: None -Published specification: this RFC draft -Applications which use this media: Various - -Fragment identifier considerations: Health+JSON follows RFC6901 for implementing + + Media type name: application + Media subtype name: health+json + Required parameters: n/a + Optional parameters: n/a + Encoding considerations: binary + Security considerations: Health+JSON shares security issues common to all JSON + content types. See RFC 8259 Section #12 for additional information. +Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such + shares security issues common to URI usage. See RFC 3986 Section #7 + for additional information. +Since Hyper+JSON can carry wide variety of data, some data may require privacy + or integrity services. This specification does not prescribe any specific + solution and assumes that concrete implementations will utilize common, trusted + approaches such as TLS/HTTPS, OAuth2 etc. + Interoperability considerations: None + Published specification: this RFC draft + Applications which use this media: Various + Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types. - -Restrictions on usage: None - -Additional information: - - - Deprecated alias names for this type: n/a - Magic number(s): n/a - File extension(s): .json - Macintosh file type code: TEXT - Object Identifiers: n/a - - -General Comments: - -Person to contact for further information: - - - Name: Irakli Nadareishvili - Email: irakli@gmail.com + Restrictions on usage: None + Additional information: + + Deprecated alias names for this type: n/a + Magic number(s): n/a + File extension(s): .json + Macintosh file type code: TEXT + Object Identifiers: n/a + + General Comments: + Person to contact for further information: + + Name: Irakli Nadareishvili + Email: irakli@gmail.com + + Intended usage: Common + Author/Change controller: Irakli Nadareishvili -Intended usage: Common -Author/Change controller: Irakli Nadareishvili -
    @@ -622,135 +613,135 @@ a fresh copy of the health check response, to assure that it is up-to-date. diff --git a/index.html b/index.html index c9242d7..92555e2 100644 --- a/index.html +++ b/index.html @@ -689,31 +689,37 @@

    7. IANA Considerations

    The media type for health check response is application/health+json.

    -

    Media type name: application Media subtype name: health+json Required parameters: n/a Optional parameters: n/a Encoding considerations: binary Security considerations: Health+JSON shares security issues common to all JSON content types. See RFC 8259 Section #12 for additional information.

    -

    Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such shares security issues common to URI usage. See RFC 3986 Section #7 for additional information.

    -

    Since Hyper+JSON can carry wide variety of data, some data may require privacy or integrity services. This specification does not prescribe any specific solution and assumes that concrete implementations will utilize common, trusted approaches such as TLS/HTTPS, OAuth2 etc.

    -

    Interoperability considerations: None Published specification: this RFC draft Applications which use this media: Various

    -

    Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types.

    -

    Restrictions on usage: None

    -

    Additional information:

    -
      +
        +
      • Media type name: application
        • +
      • Media subtype name: health+json
        • +
      • Required parameters: n/a
        • +
      • Optional parameters: n/a
        • +
      • Encoding considerations: binary
        • +
      • Security considerations: Health+JSON shares security issues common to all JSON content types. See RFC 8259 Section #12 for additional information.

        Health+JSON allows utilization of Uniform Resource Identifiers (URIs) and as such shares security issues common to URI usage. See RFC 3986 Section #7 for additional information.

        Since Hyper+JSON can carry wide variety of data, some data may require privacy or integrity services. This specification does not prescribe any specific solution and assumes that concrete implementations will utilize common, trusted approaches such as TLS/HTTPS, OAuth2 etc.
        • +
      • Interoperability considerations: None
        • +
      • Published specification: this RFC draft
        • +
      • Applications which use this media: Various
        • +
      • Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types.
        • +
      • Restrictions on usage: None
        • +
      • Additional information:
        1. Deprecated alias names for this type: n/a
        2. Magic number(s): n/a
        3. File extension(s): .json
        4. Macintosh file type code: TEXT
        5. Object Identifiers: n/a
        -

        General Comments:

        -

        Person to contact for further information:

        -

        - -
          + +
        1. General Comments:
          2. +
        2. Person to contact for further information:
          1. Name: Irakli Nadareishvili
          2. Email: irakli@gmail.com
          -

          Intended usage: Common Author/Change controller: Irakli Nadareishvili

          +
          3. +
        3. Intended usage: Common
          4. +
        4. Author/Change controller: Irakli Nadareishvili
          5. +

      8. Acknowledgements

      diff --git a/index.txt b/index.txt index 6d1f7b4..92763ad 100644 --- a/index.txt +++ b/index.txt @@ -473,31 +473,31 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 The media type for health check response is application/health+json. - Media type name: application Media subtype name: health+json Required - parameters: n/a Optional parameters: n/a Encoding considerations: - binary Security considerations: Health+JSON shares security issues - common to all JSON content types. See RFC 8259 Section #12 for - additional information. + o Media type name: application - Health+JSON allows utilization of Uniform Resource Identifiers (URIs) - and as such shares security issues common to URI usage. See RFC 3986 - Section #7 for additional information. + o Media subtype name: health+json - Since Hyper+JSON can carry wide variety of data, some data may - require privacy or integrity services. This specification does not - prescribe any specific solution and assumes that concrete - implementations will utilize common, trusted approaches such as TLS/ - HTTPS, OAuth2 etc. + o Required parameters: n/a - Interoperability considerations: None Published specification: this - RFC draft Applications which use this media: Various + o Optional parameters: n/a - Fragment identifier considerations: Health+JSON follows RFC6901 for - implementing URI Fragment Identification standard to JSON content - types. + o Encoding considerations: binary - Restrictions on usage: None + o Security considerations: Health+JSON shares security issues common + to all JSON content types. See RFC 8259 Section #12 for + additional information. + Health+JSON allows utilization of Uniform Resource Identifiers + (URIs) and as such shares security issues common to URI usage. + See RFC 3986 Section #7 for additional information. + + Since Hyper+JSON can carry wide variety of data, some data may + require privacy or integrity services. This specification does + not prescribe any specific solution and assumes that concrete + implementations will utilize common, trusted approaches such as + TLS/HTTPS, OAuth2 etc. + + o Interoperability considerations: None @@ -506,27 +506,39 @@ Nadareishvili Expires September 25, 2018 [Page 9] Internet-Draft Health Check Response Format for HTTP APIs March 2018 - Additional information: + o Published specification: this RFC draft + + o Applications which use this media: Various + + o Fragment identifier considerations: Health+JSON follows RFC6901 + for implementing URI Fragment Identification standard to JSON + content types. + + o Restrictions on usage: None + + o Additional information: - 1. Deprecated alias names for this type: n/a + 1. Deprecated alias names for this type: n/a - 2. Magic number(s): n/a + 2. Magic number(s): n/a - 3. File extension(s): .json + 3. File extension(s): .json - 4. Macintosh file type code: TEXT + 4. Macintosh file type code: TEXT - 5. Object Identifiers: n/a + 5. Object Identifiers: n/a - General Comments: + o General Comments: - Person to contact for further information: + o Person to contact for further information: - 1. Name: Irakli Nadareishvili + 1. Name: Irakli Nadareishvili - 2. Email: irakli@gmail.com + 2. Email: irakli@gmail.com - Intended usage: Common Author/Change controller: Irakli Nadareishvili + o Intended usage: Common + + o Author/Change controller: Irakli Nadareishvili 8. Acknowledgements @@ -543,6 +555,13 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 commonly-used URI, such as "health" because it will help self- discoverability by clients. + + +Nadareishvili Expires September 25, 2018 [Page 10] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + o Health check responses can be personalized. For example, you could advertise different URIs, and/or different kinds of link relations, to afford different clients access to additional health @@ -553,15 +572,6 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 determine how long they could cache them, to avoid overly frequent fetching and unintended DDOS-ing of the service. - - - - -Nadareishvili Expires September 25, 2018 [Page 10] - -Internet-Draft Health Check Response Format for HTTP APIs March 2018 - - o Custom link relation types, as well as the URIs for variables, should lead to documentation for those constructs. @@ -600,6 +610,14 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 DOI 10.17487/RFC5988, October 2010, . + + + +Nadareishvili Expires September 25, 2018 [Page 11] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, @@ -610,14 +628,6 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 DOI 10.17487/RFC8259, December 2017, . - - - -Nadareishvili Expires September 25, 2018 [Page 11] - -Internet-Draft Health Check Response Format for HTTP APIs March 2018 - - 11.2. Informative References [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: @@ -651,6 +661,19 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018 Author's Address + + + + + + + + +Nadareishvili Expires September 25, 2018 [Page 12] + +Internet-Draft Health Check Response Format for HTTP APIs March 2018 + + Irakli Nadareishvili 114 5th Avenue New York @@ -669,4 +692,37 @@ Author's Address -Nadareishvili Expires September 25, 2018 [Page 12] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Nadareishvili Expires September 25, 2018 [Page 13]