Link Relation Types for Web Services
draft-wilde-service-link-rel-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-19
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-07-01
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-06-12
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-06-10
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from In Progress |
2019-06-06
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-05-30
|
10 | (System) | IANA Action state changed to Waiting on Authors |
2019-05-20
|
10 | (System) | RFC Editor state changed to EDIT |
2019-05-20
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-05-20
|
10 | (System) | Announcement was received by RFC Editor |
2019-05-20
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-05-20
|
10 | Amy Vezza | IESG has approved the document |
2019-05-20
|
10 | Amy Vezza | Closed "Approve" ballot |
2019-05-20
|
10 | Amy Vezza | Ballot approval text was generated |
2019-05-18
|
10 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-03-22
|
10 | Stefan Santesson | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Stefan Santesson. Sent review to list. |
2019-02-04
|
10 | Alexey Melnikov | Note field has been cleared |
2019-02-03
|
10 | Tim Chown | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Chown. Sent review to list. |
2019-01-13
|
10 | Benjamin Kaduk | [Ballot comment] Thank you for the discussion relating to my Discuss point (preserved below as "OLD DISCUSS"). It seems somewhat inherent in the nature of … [Ballot comment] Thank you for the discussion relating to my Discuss point (preserved below as "OLD DISCUSS"). It seems somewhat inherent in the nature of link relations that this specification cannot guarantee that an arbitrary client following a service-descr link relation will be able to mechanically process the returned resource, and thus that any machine-readability will be subject to the implementation overlap between client and server. (Accordingly, I am clearing my Discuss position, as there is no in-scope reliable means by which to alleviate the indicated topic.) That said, we may still have scope to lay out a path for a future that improves the chances of successful machine readability. For example, Section 3.2 (Describing Web Services) concludes by noting: [...] model. Other description languages for non-RPC approaches to services will use different structuring approaches, such as structuring service descriptions by URIs and/or URI patterns. Would it be appropriate to also include some text here along the lines of "Future specifications may define machine-readable formats for describing service APIs and similar functionality, such as an OpenAPI description. If new media types are allocated for these formats, the normal HTTP Accept and content-type mechanisms can serve to give automated parsers confidence that they are processing the correct data structure. Nonetheless, these mechanisms are not a guarantee, and clients MUST always be prepared to handle unexpected content-types and response contents." OLD DISCUSS I think we may need to have a discussion about when it's appropriate to provide resources intended for machine consumption without a machine-readable way of knowing how to consume those resources. (See comments on Sections 3.2, 3.3, 4.3, and 5.) I also have some reservations about the "status" relation, or perhaps just with the way it is described. Section 1 implies that it is supposed to be about the status of the service as a whole, as opposed to potentially being limited to just the resource returning the link relation. Since web services, while widespread, are not universal, I would be reluctant to use such a generic term in the namespace for a more specific use case. The actual registration in Section 6.4 is more vague, though, talking just about the status of "the context", which I suppose could apply even to resources that are not part of a web service. It's quite possible I'm in the rough on one or both of those, in which case I'll happily clear. OLD COMMENT I agree with the directorate reviewers that there is a lot of duplicated content here and it detracts fromthe reader's experience. If we do end up pushing this as Experimental, would we have room to narrow down the semantics and representation of the status resource at such time as it is moved to the standards-track? Section 1 In addition, while both documentation and descriptions may be provided as part of a Web service, there may be other information as well. Generally speaking, a Web service may have any metadata/ resources associated with it (with documentation/description just being two specific kinds of resource). If there is a way how all of these metadata/resources are represented, then it should be possible to discover such a resource of general Web service metadata. I'm having trouble unpacking this (but I'm sick and short on sleep, so maybe it's just me). Is "way how [...] are represented" intended to mean something like "a single resourse presenting a high-level description of how these resources are organized"? Section 3.2 I'm a little uneasy about promulgating a thing that is stated as being machine-readable but without a machine-readable way to know how the contents are supposed to be interpreted. Content-type seems a bit too coarse-grained to be usable for this purpose, for example. (But if we publish as Experimental this concern mostly goes away.) Section 3.3 Are we advocating for using the "service" link relation type with no documentation on what the semantics of that link relation are supposed to be? Section 4.3 Same comment as for Section 3.2, but now about the lack of a concrete mechanism for the "hints". Section 5 A resource that may or may not be intended for machine consumption is pretty hard for a machine to consume absent a concrete signal that this instance of the resource is in fact intended for machine consumption. Section 7 Are the consumers supposed to manually verify the documentation by trying the API endpoints, or talking to the site owner out of band, or something else? Or is the "behave accordingly" just supposed to be "prepared to handle errors"? (In which case maybe it's better to say that directly.) |
2019-01-13
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-01-11
|
10 | Erik Wilde | New version available: draft-wilde-service-link-rel-10.txt |
2019-01-11
|
10 | (System) | New version approved |
2019-01-11
|
10 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2019-01-11
|
10 | Erik Wilde | Uploaded new revision |
2018-12-28
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-12-28
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-12-28
|
09 | Erik Wilde | New version available: draft-wilde-service-link-rel-09.txt |
2018-12-28
|
09 | (System) | New version approved |
2018-12-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2018-12-28
|
09 | Erik Wilde | Uploaded new revision |
2018-12-20
|
08 | Peter Yee | Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee. Sent review to list. |
2018-12-20
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-12-20
|
08 | Benjamin Kaduk | [Ballot discuss] I think we may need to have a discussion about when it's appropriate to provide resources intended for machine consumption without a machine-readable … [Ballot discuss] I think we may need to have a discussion about when it's appropriate to provide resources intended for machine consumption without a machine-readable way of knowing how to consume those resources. (See comments on Sections 3.2, 3.3, 4.3, and 5.) I also have some reservations about the "status" relation, or perhaps just with the way it is described. Section 1 implies that it is supposed to be about the status of the service as a whole, as opposed to potentially being limited to just the resource returning the link relation. Since web services, while widespread, are not universal, I would be reluctant to use such a generic term in the namespace for a more specific use case. The actual registration in Section 6.4 is more vague, though, talking just about the status of "the context", which I suppose could apply even to resources that are not part of a web service. It's quite possible I'm in the rough on one or both of those, in which case I'll happily clear. |
2018-12-20
|
08 | Benjamin Kaduk | [Ballot comment] I agree with the directorate reviewers that there is a lot of duplicated content here and it detracts fromthe reader's experience. If we … [Ballot comment] I agree with the directorate reviewers that there is a lot of duplicated content here and it detracts fromthe reader's experience. If we do end up pushing this as Experimental, would we have room to narrow down the semantics and representation of the status resource at such time as it is moved to the standards-track? Section 1 In addition, while both documentation and descriptions may be provided as part of a Web service, there may be other information as well. Generally speaking, a Web service may have any metadata/ resources associated with it (with documentation/description just being two specific kinds of resource). If there is a way how all of these metadata/resources are represented, then it should be possible to discover such a resource of general Web service metadata. I'm having trouble unpacking this (but I'm sick and short on sleep, so maybe it's just me). Is "way how [...] are represented" intended to mean something like "a single resourse presenting a high-level description of how these resources are organized"? Section 3.2 I'm a little uneasy about promulgating a thing that is stated as being machine-readable but without a machine-readable way to know how the contents are supposed to be interpreted. Content-type seems a bit too coarse-grained to be usable for this purpose, for example. (But if we publish as Experimental this concern mostly goes away.) Section 3.3 Are we advocating for using the "service" link relation type with no documentation on what the semantics of that link relation are supposed to be? Section 4.3 Same comment as for Section 3.2, but now about the lack of a concrete mechanism for the "hints". Section 5 A resource that may or may not be intended for machine consumption is pretty hard for a machine to consume absent a concrete signal that this instance of the resource is in fact intended for machine consumption. Section 7 Are the consumers supposed to manually verify the documentation by trying the API endpoints, or talking to the site owner out of band, or something else? Or is the "behave accordingly" just supposed to be "prepared to handle errors"? (In which case maybe it's better to say that directly.) |
2018-12-20
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-12-19
|
08 | Ben Campbell | [Ballot comment] Why is this informational? It seems to be defining a standard. I see that the shepherd review says it has had insufficient review … [Ballot comment] Why is this informational? It seems to be defining a standard. I see that the shepherd review says it has had insufficient review for the standards track. The reasoning should be reflected somewhere in the text of the document. (I agree with Mirja's comment that "experimental" might be the appropriate choice.) §2: I agree with comments to use the RFC 8174 boilerplate. But IDNits says there are no normative keywords used, so maybe the boilerplate should just be removed. |
2018-12-19
|
08 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-12-19
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-12-18
|
08 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this document. I have a handful of questions and comments. =========================================================================== I-D Nits reports: == The … [Ballot comment] Thanks to everyone who worked on this document. I have a handful of questions and comments. =========================================================================== I-D Nits reports: == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. --------------------------------------------------------------------------- §3.3: > In such a case, an alternative approach is to use the > "service" link relation type, which has no indication of whether it > links to documentation or description I was going to ask that the document cite RFC 5023 here, as a simple reading of this section led me to believe that *this* document was attempting to define a link relation called "service," and was confused when no such link relation appeared in the IANA section. The problem I came across was, when I went to look at the definition of the "service" link relation in RFC 5023 (the document indicated for "service" in https://www.iana.org/assignments/link-relations/link-relations.xhtml), I found that it isn't actually defined there. This situation isn't *this* document's problem, although the comment -- that this document should make it clear that the "service" link relation is not being defined by this document -- still applies. --------------------------------------------------------------------------- §4.1: > The "service-doc" link relation type is used to represent the fact > that a resource is part of a bigger set of resources... Is it necessarily part of a bigger set of resources? If so, what link relation would I use if I wanted to point to documentation for a relatively simple service that was implemented using a single endpoint? (The same comment applies to §4.2) --------------------------------------------------------------------------- §4.2 and §4.3: This text makes it pretty hard for the reader to understand the distinction being made between the "service-desc" and "service-meta" link relations. Would it be possible to include a very simple example of each? --------------------------------------------------------------------------- §5: > Such a link may not be available for > and from all resources provided by a Web service, but from key > resources such as a Web service's metadata resource and/or a > service's home resource [I-D.nottingham-json-home]. Given that the cited draft has been expired for nearly a year and a half and hasn't been adopted by a working group, are we sure that a citation to it makes sense? What is the chance that this document eventually gets published? (I ask this knowing Mark is copied on this review.) |
2018-12-18
|
08 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-12-18
|
08 | Alissa Cooper | [Ballot comment] Please use the RFC 8174 boilerplate in lieu of the RFC 2119 boilerplate. |
2018-12-18
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-12-18
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-12-17
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-12-17
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-12-17
|
08 | Spencer Dawkins | [Ballot comment] It would be helpful to me, if there was a reference for the "service" link relation type in this text: 3.3. Unified Documentation/Description … [Ballot comment] It would be helpful to me, if there was a reference for the "service" link relation type in this text: 3.3. Unified Documentation/Description If service providers use an approach where there is no distinction between service documentation (Section 3.1) and service description (Section 3.2), then they may not feel the need to use two separate links. In such a case, an alternative approach is to use the "service" link relation type, which has no indication of whether it links to documentation or description, and thus may be a better fit if no such differentiation is required. and, for extra credit, if "service" was qualified as 3.3. Unified Documentation/Description If service providers use an approach where there is no distinction between service documentation (Section 3.1) and service description (Section 3.2), then they may not feel the need to use two separate links. In such a case, an alternative approach is to use the "service" link relation type, which has no indication of whether it ^ 'existing "service" link relation type' or 'previously defined "service" link relation type', or really anything that would tell me not to bother looking through the document looking for the definition of "service" because it's already been defined ;-) links to documentation or description, and thus may be a better fit if no such differentiation is required. |
2018-12-17
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-12-14
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-12-14
|
08 | Mirja Kühlewind | [Ballot comment] These comments are mostly for the responsible AD: 1) From the shepherd write-up it sounds like this document should experimental and not informational … [Ballot comment] These comments are mostly for the responsible AD: 1) From the shepherd write-up it sounds like this document should experimental and not informational ("it hasn't been widely reviewed or implemented enough to make it standards-track"). 2) Why was this document not processed in the httpbis wg. It seems to be fully in scope for httpbis and if there is a suitable wg, I think it is always more appropriate to take the wg track with last call and and respective reviews than an individual submission. If the httpbis wg does not support this doc, it maybe shouldn't be processed in the IETF at all (and could e.g. also be published with the ISE to have a stable reference). |
2018-12-14
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-12-07
|
08 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stefan Santesson |
2018-12-07
|
08 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Stefan Santesson |
2018-12-06
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-12-06
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-12-04
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-12-03
|
08 | Amy Vezza | Placed on agenda for telechat - 2018-12-20 |
2018-12-03
|
08 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-12-03
|
08 | Alexey Melnikov | Ballot has been issued |
2018-12-03
|
08 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-12-03
|
08 | Alexey Melnikov | Created "Approve" ballot |
2018-12-03
|
08 | Alexey Melnikov | Ballot writeup was changed |
2018-12-03
|
08 | Alexey Melnikov | # Shepherd Writeup for draft-wilde-service-link-rel-08 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on … # Shepherd Writeup for draft-wilde-service-link-rel-08 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation, descriptions, or metadata for these Web services. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers; metadata is supposed to be information about a service's context. It also defines a link relation to identify status resources that are used to represent operational information about service status. ## 2. Review and Consensus This document has not seen substantial discussion in IETF fora, but the HTTP Working Group is aware of it. It has been reviewed by the various review teams across the IETF. ## 3. Intellectual Property The author confirms that to their direct, personal knowledge, all IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. ## 4. Other Points As Document Shepherd, I think Informational is appropriate for this document; it's not likely to cause harm, and it may do some good, but it hasn't been widely reviewed or implemented enough to make it standards-track. |
2018-11-29
|
08 | Mark Nottingham | # Shepherd Writeup for draft-wilde-service-link-rel-08 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on … # Shepherd Writeup for draft-wilde-service-link-rel-08 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation, descriptions, or metadata for these Web services. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers; metadata is supposed to be information about a service's context. It also defines a link relation to identify status resources that are used to represent operational information about service status. ## 2. Review and Consensus This document has not seen substantial discussion in IETF fora, but the HTTP Working Group is aware of it. It has been reviewed by the various review teams across the IETF. ## 3. Intellectual Property The author confirms that to their direct, personal knowledge, all IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. ## 4. Other Points As Document Shepherd, I think Informational is appropriate for this document; it's not likely to cause harm, and it may do some good, but it hasn't been widely reviewed or implemented enough to make it standards-track. Note that the registry status of the header field should be "Informational", not "Standard", as discussed. |
2018-11-29
|
08 | Erik Wilde | New version available: draft-wilde-service-link-rel-08.txt |
2018-11-29
|
08 | (System) | New version approved |
2018-11-29
|
08 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2018-11-29
|
08 | Erik Wilde | Uploaded new revision |
2018-11-25
|
07 | Mark Nottingham | # Shepherd Writeup for draft-wilde-service-link-rel-07 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on … # Shepherd Writeup for draft-wilde-service-link-rel-07 ## 1. Summary Mark Nottingham is the document shepherd; Alexey Melnikov is the responsible Area Director. Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation, descriptions, or metadata for these Web services. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers; metadata is supposed to be information about a service's context. It also defines a link relation to identify status resources that are used to represent operational information about service status. ## 2. Review and Consensus This document has not seen substantial discussion in IETF fora, but the HTTP Working Group is aware of it. It has been reviewed by the various review teams across the IETF. ## 3. Intellectual Property TODO - [[ Confirm that each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. Explain briefly the working group discussion about any IPR disclosures regarding this document, and summarize the outcome. ]] ## 4. Other Points As Document Shepherd, I think Informational is appropriate for this document; it's not likely to cause harm, and it may do some good, but it hasn't been widely reviewed or implemented enough to make it standards-track. Note that the registry status of the header field should be "Informational", not "Standard", as discussed. |
2018-11-20
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-11-20
|
07 | Erik Wilde | New version available: draft-wilde-service-link-rel-07.txt |
2018-11-20
|
07 | (System) | New version approved |
2018-11-20
|
07 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2018-11-20
|
07 | Erik Wilde | Uploaded new revision |
2018-11-20
|
06 | Peter Yee | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Peter Yee. Sent review to list. |
2018-11-20
|
06 | Stefan Santesson | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stefan Santesson. Sent review to list. |
2018-11-20
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-11-19
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-11-19
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-wilde-service-link-rel-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-wilde-service-link-rel-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Link Relation Types registry on the Link Relations registry page located at: https://www.iana.org/assignments/link-relations/ four, new link relation types are to be registered as follows: Relation Name: service-doc Description: Linking to service documentation that is primarily intended for human consumption. Reference: [ RFC-to-be ] Notes: Relation Name: service-desc Description: Linking to service description that is primarily intended for consumption by machines. Reference: [ RFC-to-be ] Notes: Relation Name: service-meta Description: Linking to service metadata that is primarily intended for consumption by machines. Reference: [ RFC-to-be ] Notes: Relation Name: status Description: Linking to a resource that represents the status of a Web service or API. Reference: [ RFC-to-be ] Notes: As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-10-26
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-10-26
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-10-25
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-10-25
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-10-25
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2018-10-25
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Peter Yee |
2018-10-23
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-10-23
|
06 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-11-20): From: The IESG To: IETF-Announce CC: alexey.melnikov@isode.com, mnot@mnot.net, draft-wilde-service-link-rel@ietf.org, Mark Nottingham Reply-To: … The following Last Call announcement was sent out (ends 2018-11-20): From: The IESG To: IETF-Announce CC: alexey.melnikov@isode.com, mnot@mnot.net, draft-wilde-service-link-rel@ietf.org, Mark Nottingham Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Link Relation Types for Web Services) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Link Relation Types for Web Services' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-11-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation, descriptions, or metadata for these Web services. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers; metadata is supposed to be information about a service's context. It also defines a link relation to identify status resources that are used to represent operational information about service status. The file can be obtained via https://datatracker.ietf.org/doc/draft-wilde-service-link-rel/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-wilde-service-link-rel/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-10-23
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-10-23
|
06 | Alexey Melnikov | Last call was requested |
2018-10-23
|
06 | Alexey Melnikov | Last call announcement was generated |
2018-10-23
|
06 | Alexey Melnikov | Ballot approval text was generated |
2018-10-23
|
06 | Alexey Melnikov | Ballot writeup was generated |
2018-10-23
|
06 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation |
2018-10-23
|
06 | Alexey Melnikov | Changed consensus to Yes from Unknown |
2018-10-17
|
06 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested::External Party |
2018-10-17
|
06 | Alexey Melnikov | Notification list changed to Mark Nottingham <mnot@mnot.net> |
2018-10-17
|
06 | Alexey Melnikov | Document shepherd changed to Mark Nottingham |
2018-09-07
|
06 | Alexey Melnikov | Waiting for feedback from HTTPBIS WG mailing list. |
2018-09-07
|
06 | Alexey Melnikov | IESG state changed to Publication Requested::External Party from Publication Requested |
2018-08-29
|
06 | Alexey Melnikov | Assigned to Applications and Real-Time Area |
2018-08-29
|
06 | Alexey Melnikov | Note added 'Checking with HTTPBIS whether there are any objections to publish.' |
2018-08-29
|
06 | Alexey Melnikov | Responsible AD changed to Alexey Melnikov |
2018-08-29
|
06 | Alexey Melnikov | IESG process started in state Publication Requested |
2018-08-29
|
06 | Alexey Melnikov | Stream changed to IETF from None |
2018-08-29
|
06 | Alexey Melnikov | Intended Status changed to Informational from None |
2018-08-01
|
06 | Erik Wilde | New version available: draft-wilde-service-link-rel-06.txt |
2018-08-01
|
06 | (System) | New version approved |
2018-08-01
|
06 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2018-08-01
|
06 | Erik Wilde | Uploaded new revision |
2018-07-27
|
05 | (System) | Document has expired |
2018-01-23
|
05 | Erik Wilde | New version available: draft-wilde-service-link-rel-05.txt |
2018-01-23
|
05 | (System) | New version approved |
2018-01-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2018-01-23
|
05 | Erik Wilde | Uploaded new revision |
2017-08-01
|
04 | Erik Wilde | New version available: draft-wilde-service-link-rel-04.txt |
2017-08-01
|
04 | (System) | New version approved |
2017-08-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2017-08-01
|
04 | Erik Wilde | Uploaded new revision |
2017-03-13
|
03 | Erik Wilde | New version available: draft-wilde-service-link-rel-03.txt |
2017-03-13
|
03 | (System) | New version approved |
2017-03-13
|
03 | (System) | Request for posting confirmation emailed to previous authors: Erik Wilde |
2017-03-13
|
03 | Erik Wilde | Uploaded new revision |
2017-02-18
|
02 | (System) | Document has expired |
2016-08-17
|
02 | Erik Wilde | New version available: draft-wilde-service-link-rel-02.txt |
2016-02-22
|
01 | Erik Wilde | New version available: draft-wilde-service-link-rel-01.txt |
2015-04-22
|
00 | Erik Wilde | New version available: draft-wilde-service-link-rel-00.txt |