Skip to main content

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