Network Working Group J. Montoya
Internet-Draft Mountain State Software Solutions
Intended status: Informational February 26, 2019
Expires: August 30, 2019
Extended Link Relationships
draft-montoya-xrel-00
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 August 30, 2019.
Copyright Notice
Copyright (c) 2019 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 August 30, 2019 [Page 1]
Internet-Draft xrel February 2019
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.1.3. Documents description . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
2. XREL Documents . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship Object . . . . . . . . . . . . . . . . . . . 5
2.2.1. Properties . . . . . . . . . . . . . . . . . . . . . 5
2.3. XREL Document . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Document Example . . . . . . . . . . . . . . . . . . 5
2.4. XREL Collection Document . . . . . . . . . . . . . . . . 6
2.4.1. Document Example . . . . . . . . . . . . . . . . . . 6
2.5. Identifying XREL Documents . . . . . . . . . . . . . . . 6
2.6. Fragment identifiers . . . . . . . . . . . . . . . . . . 6
2.7. Identifying XREL Relationships . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
3.1. application/xrel . . . . . . . . . . . . . . . . . . . . 7
4. Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . 8
5. Appendix B. Frequently Asked Questions . . . . . . . . . . . 8
5.1. How can I submit comments or feedback to the editors? . . 8
5.2. Why not include target attributes as defined by RFC8288
'Web Linking'? . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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 August 30, 2019 [Page 2]
Internet-Draft xrel February 2019
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.
This document and the specification documented in it are heavily
influenced by the RAML 1.0 Spec [RAML].
Montoya Expires August 30, 2019 [Page 3]
Internet-Draft xrel February 2019
1.1.3. Documents description
A trailing question mark, for example *description?*, indicates an
optional property.
Throughout this specification, *markdown* means GitHub-Flavored
Markdown [github.md]. Tooling MAY choose to ignore some Markdown
features to address security concerns.
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
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. XREL Documents
2.1. Format
Following RAML conventions, XREL documents are YAML documents. The
file extension ".yaml" SHALL be used to designate files containing
XREL documents.
Montoya Expires August 30, 2019 [Page 4]
Internet-Draft xrel February 2019
This specification uses YAML 1.2 [W3C.yaml] as its underlying format.
YAML is a human-readable data format that aligns well with the design
goals of this specification. As in YAML, all nodes such as keys,
values, and tags, are case-sensitive.
To facilitate the automated processing of XREL documents, XREL
imposes the following restrictions and requirements in addition to
the core YAML 1.2 specification:
o The first line of a XREL file consists of a YAML comment that
specifies the XREL version and document type. Therefore, XREL
processors cannot completely ignore all YAML comments.
2.2. Relationship Object
Explains the semantics of a hypermedia relationship.
2.2.1. Properties
+-------------+--------+--------------------------------------------+
| Name | Type | Description |
+-------------+--------+--------------------------------------------+
| description | string | 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.3. XREL Document
Defines a single Relationship Object.
The first line of a XREL document MUST begin with the text "#%XREL
1.0" followed by nothing but the end of the line.
2.3.1. Document Example
#%XREL 1.0
description: Refers to an event scheduling service resource related to the context resource.
Montoya Expires August 30, 2019 [Page 5]
Internet-Draft xrel February 2019
2.4. XREL Collection Document
Defines a map where the keys are the document scoped relationship
names and the values are Relationship Objects. XREL Collections can
be used to combine any collection of Relationship Objects.
The first line of a collection document MUST begin with the text
"#%XREL 1.0 Collection" followed by nothing but the end of the line.
2.4.1. Document Example
#%XREL 1.0 Collection
schedulingService:
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, this 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.
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/shedulingService* 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#/shedulingService* and
Montoya Expires August 30, 2019 [Page 6]
Internet-Draft xrel February 2019
*http://docs.example.org/xrels/clinical#/patient* identify the first
and second Relationship Object, respectively.
3. IANA Considerations
This specification establishes the media type "application/xrel" for
community review and will be submitted to the IESG for review,
approval, and registration with IANA.
3.1. application/xrel
*Type name:* application
*Subtype name:* xrel
*Required parameters:* none
*Optional parameters:*
*profile:*: A whitespace-separated list of URIs identifying
specific constraints or conventions that apply to an XREL
document. A profile must not change the semantics of the resource
representation when processed without profile knowledge, so that
clients both with and without knowledge of a profiled resource can
safely use the same representation. The profile parameter may
also be used by clients to express their preferences in the
content negotiation process. It is recommended that profile URIs
are dereferenceable and provide useful documentation at that URI.
*Encoding considerations:*
*binary:* Because of YAML's relation to JSON the same encoding
considerations of application/json as specified in JavaScript
Object Notation [RFC3986] 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
JavaScript Object Notation [RFC3986], section 6, should be
considered.
*Interoperability considerations:* none
*Fragment identifier considerations:*
Fragment identifiers are to be computed as defined by the JSON
Pointer [2] specification.
Montoya Expires August 30, 2019 [Page 7]
Internet-Draft xrel February 2019
*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
4. 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.
5. Appendix B. Frequently Asked Questions
5.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 [3]. For additional
information, see https://phtal-org.github.io/internet-draft-xrel/
[4].
To provide feedback, use this issue tracker, the communication
methods listed on the homepage, or email the document editors.
5.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
Montoya Expires August 30, 2019 [Page 8]
Internet-Draft xrel February 2019
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
representations and link relations in any way they wish and to
provide them in any order, all while remaining understandable to the
client.
6. References
6.1. Normative References
[github.md]
McFarlane, J., "GitHub Flavored Markdown Spec", n.d.,
<https://github.github.com/gfm/>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <https://www.rfc-editor.org/info/rfc1738>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[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>.
[RFC7320] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 7320, DOI 10.17487/RFC7320, July 2014,
<https://www.rfc-editor.org/info/rfc7320>.
[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>.
Montoya Expires August 30, 2019 [Page 9]
Internet-Draft xrel February 2019
[W3C.yaml]
Ben Kiki, O, ., Evans, C, ., and I. Net, "YAML Aint Markup
Language", 2009, <http://www.yaml.org/spec/1.2/spec.html>.
6.2. Informative References
[RAML] The RAML Workgroup, "RAML Specification", n.d.,
<https://github.com/raml-org/raml-
spec/blob/master/versions/raml-10/raml-10.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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[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>.
6.3. URIs
[1] RFC6901
[2] RFC6901
[3] https://github.com/phtal-org/internet-draft-xrel/issues
[4] https://phtal-org.github.io/internet-draft-xrel/
Author's Address
Jose Montoya
Mountain State Software Solutions
Email: jmontoya@ms3-inc.com
Montoya Expires August 30, 2019 [Page 10]