Skip to content

Commit

Permalink
rebuilt generated spec files
Browse files Browse the repository at this point in the history
  • Loading branch information
@inadarei
inadarei committed Mar 24, 2018
1 parent 30174f7 commit 31b158a
Show file tree
Hide file tree
Showing 5 changed files with 413 additions and 298 deletions.
34 changes: 20 additions & 14 deletions draft-inadarei-api-health-check-01.html
View file
Expand Up @@ -689,31 +689,37 @@ <h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#iana-considerations" id="iana-considerations">IANA Considerations</a>
</h1>
<p id="rfc.section.7.p.1">The media type for health check response is application/health+json.</p>
<p id="rfc.section.7.p.2">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.</p>
<p id="rfc.section.7.p.3">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.</p>
<p id="rfc.section.7.p.4">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.</p>
<p id="rfc.section.7.p.5">Interoperability considerations: None Published specification: this RFC draft Applications which use this media: Various</p>
<p id="rfc.section.7.p.6">Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types.</p>
<p id="rfc.section.7.p.7">Restrictions on usage: None</p>
<p id="rfc.section.7.p.8">Additional information:</p>
<p></p>

<ol>
<ul>
<li>Media type name: application</li>
<li>Media subtype name: health+json</li>
<li>Required parameters: n/a</li>
<li>Optional parameters: n/a</li>
<li>Encoding considerations: binary</li>
<li>Security considerations: Health+JSON shares security issues common to all JSON content types. See RFC 8259 Section #12 for additional information. <br><br> 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. <br><br> 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.</li>
<li>Interoperability considerations: None</li>
<li>Published specification: this RFC draft</li>
<li>Applications which use this media: Various</li>
<li>Fragment identifier considerations: Health+JSON follows RFC6901 for implementing URI Fragment Identification standard to JSON content types.</li>
<li>Restrictions on usage: None</li>
<li>Additional information: <ol>
<li>Deprecated alias names for this type: n/a</li>
<li>Magic number(s): n/a</li>
<li>File extension(s): .json</li>
<li>Macintosh file type code: TEXT</li>
<li>Object Identifiers: n/a</li>
</ol>
<p id="rfc.section.7.p.10">General Comments:</p>
<p id="rfc.section.7.p.11">Person to contact for further information:</p>
<p></p>

<ol>
</li>
<li>General Comments:</li>
<li>Person to contact for further information: <ol>
<li>Name: Irakli Nadareishvili</li>
<li>Email: irakli@gmail.com</li>
</ol>
<p id="rfc.section.7.p.13">Intended usage: Common Author/Change controller: Irakli Nadareishvili</p>
</li>
<li>Intended usage: Common</li>
<li>Author/Change controller: Irakli Nadareishvili</li>
</ul>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#acknowledgements" id="acknowledgements">Acknowledgements</a>
</h1>
Expand Down
152 changes: 104 additions & 48 deletions draft-inadarei-api-health-check-01.txt
View file
Expand Up @@ -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



Expand All @@ -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

Expand All @@ -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
Expand All @@ -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.

Expand Down Expand Up @@ -600,6 +610,14 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.




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,
Expand All @@ -610,14 +628,6 @@ Internet-Draft Health Check Response Format for HTTP APIs March 2018
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.




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:
Expand Down Expand Up @@ -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
Expand All @@ -669,4 +692,37 @@ Author's Address



Nadareishvili Expires September 25, 2018 [Page 12]

































Nadareishvili Expires September 25, 2018 [Page 13]

0 comments on commit 31b158a

Please sign in to comment.