[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         J. Montoya
Internet-Draft                                              May 05, 2020
Intended status: Informational
Expires: November 6, 2020


                      Extended Link Relationships
                         draft-montoya-xrel-02

Abstract

   This document defines XREL, a data format for describing extended
   hypermedia relationships identified by Uniform Resource Locators.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 6, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Montoya                 Expires November 6, 2020                [Page 1]


Internet-Draft                    xrel                          May 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Definitions and Terminology . . . . . . . . . . . . . . .   2
       1.1.1.  Terminology and Conformance Language  . . . . . . . .   3
       1.1.2.  General . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Format  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Rich Text Formatting  . . . . . . . . . . . . . . . . . .   4
     2.3.  Schema  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.1.  Relationship Object . . . . . . . . . . . . . . . . .   5
     2.4.  Document Types  . . . . . . . . . . . . . . . . . . . . .   5
       2.4.1.  XREL Document . . . . . . . . . . . . . . . . . . . .   5
       2.4.2.  XREL Collection Document  . . . . . . . . . . . . . .   6
     2.5.  Identifying XREL Documents  . . . . . . . . . . . . . . .   6
     2.6.  Fragment identifiers  . . . . . . . . . . . . . . . . . .   6
     2.7.  Identifying XREL Relationships  . . . . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  application/xrel  . . . . . . . . . . . . . . . . . . . .   7
     4.2.  application/xrel+json . . . . . . . . . . . . . . . . . .   9
   5.  Appendix A. Acknowledgments . . . . . . . . . . . . . . . . .  10
   6.  Appendix B. Frequently Asked Questions  . . . . . . . . . . .  10
     6.1.  How can I submit comments or feedback to the editors? . .  10
     6.2.  Why not include target attributes as defined by RFC8288
           'Web Linking'?  . . . . . . . . . . . . . . . . . . . . .  10
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     7.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document defines XREL, a data format for describing extended
   hypermedia relationships identified by Uniform Resource Locators.

   This document registers a media-type identifier with the IANA:
   "application/xrel".  This registration is for community review and
   will be submitted to the IESG for review, approval, and registration
   with IANA.

1.1.  Definitions and Terminology







Montoya                 Expires November 6, 2020                [Page 2]


Internet-Draft                    xrel                          May 2020


1.1.1.  Terminology and Conformance Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.1.2.  General

   Representational State Transfer, or [REST], is an architectural style
   for distributed hypermedia systems.  Introduced and first defined in
   2000 in Chapter 5, REST, of the doctoral dissertation "Architectural
   Styles and the Design of Network-based Software Architecture" by Roy
   Fielding.

   *Hypermedia*, or hypertext, is defined by the presence of application
   control information embedded within, or as a layer above, the
   presentation of information.  Hypermedia allows for a virtually
   unbound network of resources while also guiding users through an
   application as they navigate said relationships.

   A *hypermedia relationship*, also known as a link relation, describes
   the semantics behind a virtual uni-directional association between
   two resources.

   A *hypermedia relationship name* is an identifier for a hypermedia
   relationship.

   A *resource* is the intended conceptual target of a hypertext
   reference.

   *Representational state* indicates the current state of the requested
   resource, the desired state for the requested resource, or the value
   of some other resource, such as a representation of the input data
   within a client's query form, or a representation of some error
   condition for a response.

   *Application state* is the state of the user's application of
   computing to a given task, controlled and stored by the user agent
   and can be composed of representations from multiple servers.

1.2.  Motivation

   The Uniform Interface constraint of the REST architectural style
   dictates that hypermedia be the engine of application state.  This
   means that the state of the application and its potential transitions
   are dictated by the presence of hypermedia relationships in-band and



Montoya                 Expires November 6, 2020                [Page 3]


Internet-Draft                    xrel                          May 2020


   by the navigation of those relationships by an user (human or
   automated).  In order for users to evaluate and select the
   appropriate relationships to navigate they must rely on an out-band
   understanding of relationships by their names.

   While humans can derive meaning from relationship names in natural
   language, automated agents have relied on a central repository of
   standard names maintained by the Internet Assigned Numbers Authority
   (IANA).  Instead of creating and registering entirely new link
   relations (i.e. "patient", "appointment", "schedulingService", etc.)
   with a central repository, authors can choose to create an XREL
   document; one that explains the vital, perhaps domain-specific,
   semantics of the relationship and which is identified by an URL
   controlled by the author.

   This decentralization allows for a much lower entry barrier, which is
   not inconsistent with the general concept of the web, and enables
   different use cases.  For example, a private organization is fully
   capable of defining their own repository of XREL definitions outside
   of the open Internet, after all standards are a byproduct of
   authority.  Conversely, public XREL definitions would allow for
   serendipitous reuse, where useful relationships backed by stable URLs
   might be discovered and possibly become de facto standard.

2.  Specification

   This document and the specification documented in it are heavily
   influenced by the OpenAPI 3.1 Spec [OAS].

2.1.  Format

   Following the OpenAPI specification, XREL documents may be
   represented either in JSON [RFC6901] or YAML [W3C.yaml] format.

   All field names in the specification are case sensitive.  This
   includes all fields that are used as keys in a map, except where
   explicitly noted that keys are case insensitive.

2.2.  Rich Text Formatting

   Throughout the specification "description" fields are noted as
   supporting CommonMark markdown formatting.

   Where XREL tooling renders rich text it MUST support, at a minimum,
   markdown syntax as described by CommonMark 0.27 [CommonMark].
   Tooling MAY choose to ignore some CommonMark features to address
   security concerns.




Montoya                 Expires November 6, 2020                [Page 4]


Internet-Draft                    xrel                          May 2020


2.3.  Schema

   In the following description, if a field is not explicitly *REQUIRED*
   or described with a MUST or SHALL, it can be considered OPTIONAL.

2.3.1.  Relationship Object

   Explains the semantics of a hypermedia relationship.

2.3.1.1.  Properties

   +-------------+--------+--------------------------------------------+
   | Name        |  Type  | Description                                |
   +-------------+--------+--------------------------------------------+
   | description | string | *REQUIRED* Describes the semantics of a    |
   |             |        | hypermedia relationship. The semantics     |
   |             |        | SHOULD describe the relationship of the    |
   |             |        | target resource to the context resource,   |
   |             |        | and not any particular representation      |
   |             |        | formats. Markdown MAY be used for rich     |
   |             |        | text representation.                       |
   +-------------+--------+--------------------------------------------+

2.4.  Document Types

2.4.1.  XREL Document

   +-----------------------------------+-------------------------------+
   | Type                              | Description                   |
   +-----------------------------------+-------------------------------+
   | Relationship Object               | A single Relationship Object. |
   | (Section 2.3.1)                   |                               |
   +-----------------------------------+-------------------------------+

2.4.1.1.  Examples

  description: Refers to an event scheduling service resource related to
    the context resource.

   {
     "description": "Refers to an event scheduling service resource
       related to the context resource."
   }








Montoya                 Expires November 6, 2020                [Page 5]


Internet-Draft                    xrel                          May 2020


2.4.2.  XREL Collection Document

   +----------------+--------------------------------------------------+
   | Type           | Description                                      |
   +----------------+--------------------------------------------------+
   | Map["string",  | A map where the keys are the document scoped     |
   | Relationship   | relationship names and the values are            |
   | Object (Sectio | Relationship Objects. XREL Collections can be    |
   | n 2.3.1)]      | used to group any number of Relationship         |
   |                | Objects.                                         |
   +----------------+--------------------------------------------------+

2.4.2.1.  Examples

   scheduling-service:
     description: Refers to an event scheduling service resource related
       to the context resource.
   patient:
     description: Refers to a patient resource related to the context
       resource.

 {
   "scheduling-service": {
     "description": "Refers to an event scheduling service resource
       related to the context resource."
   },
   "patient": {
     "description": "Refers to a patient resource related to the context
       resource."
   }
 }

2.5.  Identifying XREL Documents

   XREL documents are identified by unique URLs, these URL SHOULD be
   dereferenceable.

   In order to reduce load on servers responding to XREL document
   requests, it is RECOMMENDED that servers use cache control directives
   that instruct client apps to locally cache the results.  Clients
   making these XREL document requests SHOULD honor the server's caching
   directives.

2.6.  Fragment identifiers

   When applied to an XREL document, a URI fragment identifier MUST be a
   JSON Pointer [1] and be computed as such.




Montoya                 Expires November 6, 2020                [Page 6]


Internet-Draft                    xrel                          May 2020


2.7.  Identifying XREL Relationships

   In the case of XREL Documents as specified in Section 2.3, the URL
   that identifies that document also identifies the hypermedia
   relationship described in that document.  For example, if the
   document example in Section 2.3.1 is served at
   *http://docs.example.org/xrels/sheduling-service* then this URL is
   the identifier for the relationship described in that document.

   In the case of XREL Collection Documents as specified in Section 2.4,
   fragment identifiers MUST be used for the relationships objects
   described in that document.  For example, if the document example in
   Section 2.4.1 is served at *http://docs.example.org/xrels/clinical*
   then *http://docs.example.org/xrels/clinical#/sheduling-service* and
   *http://docs.example.org/xrels/clinical#/patient* identify the first
   and second Relationship Objects, respectively.

3.  Security Considerations

   This document registers two media types in the following section,
   IANA Considerations.  See the Security Considerations for each type
   in that section.

4.  IANA Considerations

   This specification establishes the media type "application/xrel" and
   "application/xrel+json" for community review and will be submitted to
   the IESG for review, approval, and registration with IANA.

4.1.  application/xrel

   *Type name:* application

   *Subtype name:* xrel

   *Required parameters:* none

   *Optional parameters:*

      *type*: The "type" parameter has a value of "collection" or
      "single".

      Neither the parameter name nor its value are case sensitive.

      The value "single" indicates that the media type identifies an
      XREL Document.





Montoya                 Expires November 6, 2020                [Page 7]


Internet-Draft                    xrel                          May 2020


      The value "collection" indicates that the media type identifies an
      XREL Collection Document.

      If not specified, the type is assumed to be "single".

   *Encoding considerations:*

      *binary:* Because of YAML's relation to JSON the same encoding
      considerations of JSON, as specified in [RFC8259], apply.

   *Security considerations:*

      Because of YAML's relation to JSON this format shares security
      issues common to all JSON content types.  The security issues of
      [RFC8259], section 6, should be considered.

   *Interoperability considerations:* none

   *Fragment identifier considerations:*

      Fragment identifiers MUST be computed as defined by the [RFC6901]
      JSON Pointer specification.

   *Published specification:* This Document

   *Applications that use this media type:* Various

   *Additional information:*

      *magic number(s):* none

      *file extensions:* .yaml

      *macintosh type file code:* TEXT

      *object idenfiers:* none

   *Person to contact for further information:*

      *Name:* Jose Montoya

      *Email:* jmontoya@ms3-inc.com

   *Intended usage:* Common

   *Author/change controller:* Jose Montoya





Montoya                 Expires November 6, 2020                [Page 8]


Internet-Draft                    xrel                          May 2020


4.2.  application/xrel+json

   *Type name:* application

   *Subtype name:* xrel+json

   *Required parameters:* none

   *Optional parameters:*

      *type*: The "type" parameter has a value of "collection" or
      "single".

      Neither the parameter name nor its value are case sensitive.

      The value "single" indicates that the media type identifies an
      XREL Document.

      The value "collection" indicates that the media type identifies an
      XREL Collection Document.

      If not specified, the type is assumed to be "single".

   *Encoding considerations:*

      *binary:* The same encoding considerations of JSON, as specified
      in [RFC8259], apply.

   *Security considerations:*

      This media type shares security issues common to all JSON content
      types.  The security issues of [RFC8259], section 6, should be
      considered.

   *Interoperability considerations:* none

   *Fragment identifier considerations:*

      Fragment identifiers MUST be computed as defined by the [RFC6901]
      JSON Pointer specification.

   *Published specification:* This Document

   *Applications that use this media type:* Various

   *Additional information:*

      *magic number(s):* none



Montoya                 Expires November 6, 2020                [Page 9]


Internet-Draft                    xrel                          May 2020


      *file extensions:* .json

      *macintosh type file code:* TEXT

      *object idenfiers:* none

   *Person to contact for further information:*

      *Name:* Jose Montoya

      *Email:* jmontoya@ms3-inc.com

   *Intended usage:* Common

   *Author/change controller:* Jose Montoya

5.  Appendix A.  Acknowledgments

   Many thanks to Mike Amundsen, Jeff Michaud, Stu Charlton, Eric Wilde
   and Darrel Miller for their contributions in this space, even if not
   directly related to XREL documents.

6.  Appendix B.  Frequently Asked Questions

6.1.  How can I submit comments or feedback to the editors?

   The issues list for this draft can be found at https://github.com/
   phtal-org/internet-draft-xrel/issues [2].  For additional
   information, see https://phtal-org.github.io/internet-draft-xrel/
   [3].

   To provide feedback, use this issue tracker, the communication
   methods listed on the homepage, or email the document editors.

6.2.  Why not include target attributes as defined by RFC8288 'Web
      Linking'?

   Link relations are universal, they describe an _association_ to a
   conceptual target and not the targets themselves nor their
   representations.  It is the responsibility of the application authors
   to communicate to their clients what data types are necessary to
   navigate a relationship and/or the data types that might be expected
   as a result.

   This level of abstraction has value because it's easier to
   standardize representations (HTML Microformats, RAML data types,
   etc.) and link relations than it is to standardize objects and
   object-specific interfaces.  Application servers are free to combine



Montoya                 Expires November 6, 2020               [Page 10]


Internet-Draft                    xrel                          May 2020


   representations and link relations in any way they wish and to
   provide them in any order, all while remaining understandable to the
   client.

7.  References

7.1.  Normative References

   [CommonMark]
              McFarlane, J., "CommonMark Spec", n.d.,
              <https://spec.commonmark.org/0.27/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6901]  Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
              "JavaScript Object Notation (JSON) Pointer", RFC 6901,
              DOI 10.17487/RFC6901, April 2013,
              <https://www.rfc-editor.org/info/rfc6901>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [W3C.yaml]
              Ben Kiki, O, ., Evans, C, ., and I. Net, "YAML Aint Markup
              Language", 2009, <http://www.yaml.org/spec/1.2/spec.html>.

7.2.  Informative References

   [OAS]      OpenAPI Initiative, a Linux Foundation Collaborative
              Project, "OpenAPI Specification", n.d.,
              <https://github.com/OAI/OpenAPI-Specification/blob/v3.1.0-
              dev/versions/3.1.0.md>.

   [REST]     Fielding, R., "Architectural Styles and the Design of
              Network-based Software Architectures", Ph.D. Dissertation,
              University of California, Irvine, 2000,
              <http://www.ics.uci.edu/~fielding/pubs/dissertation/
              fielding_dissertation.pdf>.




Montoya                 Expires November 6, 2020               [Page 11]


Internet-Draft                    xrel                          May 2020


   [untangled]
              Fielding, R., "Untangled, musings of Roy T. Fielding",
              n.d., <http://roy.gbiv.com/untangled/>.

   [yahoo.rest]
              "The REST Architectural Style List", n.d.,
              <https://groups.yahoo.com/neo/groups/rest-discuss/info>.

7.3.  URIs

   [1] RFC6901

   [2] https://github.com/phtal-org/internet-draft-xrel/issues

   [3] https://phtal-org.github.io/internet-draft-xrel/

Author's Address

   Jose Montoya

   Email: jam01@protonmail.com






























Montoya                 Expires November 6, 2020               [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/