draft-ietf-core-link-format-05.txt   draft-ietf-core-link-format-06.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track May 22, 2011 Intended status: Standards Track June 15, 2011
Expires: November 23, 2011 Expires: December 17, 2011
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-05 draft-ietf-core-link-format-06
Abstract Abstract
This document defines Web Linking using a link format for use by This document defines Web Linking using a link format for use by
constrained web servers to describe hosted resources, their constrained web servers to describe hosted resources, their
attributes and other relationships between links. Based on the HTTP attributes and other relationships between links. Based on the HTTP
Link Header format defined in RFC5988, the CoRE Link Format is Link Header format defined in RFC5988, the CoRE Link Format is
carried as a payload and is assigned an Internet media type. A well- carried as a payload and is assigned an Internet media type. A well-
known URI is defined as a default entry-point for requesting the known URI is defined as a default entry-point for requesting the
links hosted by a server. links hosted by a server.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2011. This Internet-Draft will expire on December 17, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7.1. Well-known 'core' URI . . . . . . . . . . . . . . . . . . 14 7.1. Well-known 'core' URI . . . . . . . . . . . . . . . . . . 14
7.2. New 'hosts' relation type . . . . . . . . . . . . . . . . 14 7.2. New 'hosts' relation type . . . . . . . . . . . . . . . . 14
7.3. New link-format Internet media type . . . . . . . . . . . 14 7.3. New link-format Internet media type . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Constrained RESTful Environments (CoRE) working group aims at The Constrained RESTful Environments (CoRE) working group aims at
realizing the Representational State Transfer (REST) architecture realizing the Representational State Transfer (REST) architecture
[REST] in a suitable form for the most constrained nodes (e.g. 8-bit [REST] in a suitable form for the most constrained nodes (e.g. 8-bit
microcontrollers with limited memoryt) and networks (e.g. 6LoWPAN microcontrollers with limited memoryt) and networks (e.g. 6LoWPAN
[RFC4944]). CoRE is aimed at Machine-to-Machine (M2M) applications [RFC4944]). CoRE is aimed at Machine-to-Machine (M2M) applications
such as smart energy and building automation. such as smart energy and building automation.
skipping to change at page 6, line 49 skipping to change at page 6, line 49
characteristics for CoRE. It should be noted that this link format characteristics for CoRE. It should be noted that this link format
is just one serialization of typed links defined in [RFC5988], others is just one serialization of typed links defined in [RFC5988], others
include HTML link, Atom feed links [RFC4287] or HTTP Link Headers. include HTML link, Atom feed links [RFC4287] or HTTP Link Headers.
It is expected that resources discovered in the CoRE Link Format may It is expected that resources discovered in the CoRE Link Format may
also be made available in alternative formats on the greater also be made available in alternative formats on the greater
Internet. The CoRE Link Format is only expected to be supported in Internet. The CoRE Link Format is only expected to be supported in
constrained networks and M2M systems. constrained networks and M2M systems.
Section 5 of [RFC5988] did not require an Internet media type for the Section 5 of [RFC5988] did not require an Internet media type for the
defined link format, as it was defined to be carried in an HTTP defined link format, as it was defined to be carried in an HTTP
header. This specification thus defines a Internet media type for header. This specification thus defines a Internet media type
the CoRE Link Format (see Section 7.3). "application/link-format" for the CoRE Link Format (see Section 7.3).
Whereas the HTTP Link Header format depends on [RFC2616] for its
encoding, the CoRE Link Format is encoded as UTF-8 [RFC3629]. A
decoder of the format is not expected to (but not prohibited from)
validate UTF-8 encoding and doesn't need to perform any UTF-8
normalization. UTF-8 data can be compared bit-wise, which allows
values to contain UTF-8 data without any added complexity for
constrained nodes.
The CoRE link format uses the ABNF description and associated rules The CoRE link format uses the ABNF description and associated rules
in Section 5 of [RFC5988]. In addition, the pchar rule is taken from in Section 5 of [RFC5988]. In addition, the pchar rule is taken from
[RFC3986]. The "Link:" text is omitted as that is part of the HTTP [RFC3986]. The "Link:" text is omitted as that is part of the HTTP
Link Header. As in [RFC5988], multiple link descriptions are Link Header. As in [RFC5988], multiple link descriptions are
separated by commas. Note that commas can also occur in quoted separated by commas. Note that commas can also occur in quoted
strings and URIs but do not end a description. strings and URIs but do not end a description.
2.1. Target and context URIs 2.1. Target and context URIs
skipping to change at page 10, line 45 skipping to change at page 10, line 47
interactions: interactions:
o Performing a GET on /.well-known/core to the default port returns o Performing a GET on /.well-known/core to the default port returns
a set of links available from the server (if any) in the CoRE Link a set of links available from the server (if any) in the CoRE Link
Format. These links might describe resources hosted on that Format. These links might describe resources hosted on that
server, on other servers, or express other kinds of link relations server, on other servers, or express other kinds of link relations
as described in Section 2. as described in Section 2.
o Filtering may be performed on any of the link format attributes o Filtering may be performed on any of the link format attributes
using a query string as specified in Section 4.1. For example using a query string as specified in Section 4.1. For example
[GET /.well-known/core?n=TemperatureC] would request resources [GET /.well-known/core?rt=TemperatureC] would request resources
with the name TemperatureC. A server is not however required to with the name TemperatureC. A server is not however required to
support filtering. support filtering.
o More capable servers such as proxies could support a resource o More capable servers such as proxies could support a resource
directory by requesting the resource descriptions of other end- directory by requesting the resource descriptions of other end-
points or allowing servers to POST requests to /.well-known/core. points or allowing servers to POST requests to /.well-known/core.
The details of such resource directory functionality is however The details of such resource directory functionality is however
out of scope for this document, and is expected to be specified out of scope for this document, and is expected to be specified
separately. separately.
4.1. Query Filtering 4.1. Query Filtering
A server implementing this document MAY recognize the query part of a A server implementing this document MAY recognize the query part of a
resource discovery URI as a filter on the resources to be returned. resource discovery URI as a filter on the resources to be returned.
The query part should conform to the following syntax. Note that The query part should conform to the following syntax. Note that
this only defines querying for a single parameter at a time. this only defines querying for a single parameter at a time.
skipping to change at page 13, line 8 skipping to change at page 13, line 8
RES: 2.05 "Content" RES: 2.05 "Content"
</sensors/light>;ct=41;rt="LightLux";if="sensor" </sensors/light>;ct=41;rt="LightLux";if="sensor"
This example shows the use of an anchor attribute to relate the This example shows the use of an anchor attribute to relate the
temperature sensor resource to an external description and to an temperature sensor resource to an external description and to an
alternative URL. alternative URL.
REQ: GET /.well-known/core REQ: GET /.well-known/core
RES: 2.05 "Content" RES: 2.05 "Content"
</sensors>;ct=40;rt="index";rt="Sensor Index", </sensors>;ct=40;rt="index";title="Sensor Index",
</sensors/temp>;rt="TemperatureC";if="sensor", </sensors/temp>;rt="TemperatureC";if="sensor",
</sensors/light>;ct=41;rt="LightLux";if="sensor", </sensors/light>;ct=41;rt="LightLux";if="sensor",
<http://www.example.com/sensors/t123>;anchor="/sensors/temp" <http://www.example.com/sensors/t123>;anchor="/sensors/temp"
;rel="describedby", ;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate" </t>;anchor="/sensors/temp";rel="alternate"
If a client is interested to find relations about a particular If a client is interested to find relations about a particular
resource, it can perform a query on the anchor parameter: resource, it can perform a query on the anchor parameter:
REQ: GET /.well-known/core?anchor=/sensors/temp REQ: GET /.well-known/core?anchor=/sensors/temp
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Thanks to Michael Stuber, Richard Kelsey, Cullen Jennings, Guido Thanks to Michael Stuber, Richard Kelsey, Cullen Jennings, Guido
Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Alexey Moritz, Peter Van Der Stok, Adriano Pezzuto, Lisa Dussealt, Alexey
Melnikov, Gilbert Clark, Salvatore Loreto, Petri Mutka, Szymon Sasin, Melnikov, Gilbert Clark, Salvatore Loreto, Petri Mutka, Szymon Sasin,
Robert Quattlebaum, Robert Cragie, Angelo Castellani, Tom Herbst, Ed Robert Quattlebaum, Robert Cragie, Angelo Castellani, Tom Herbst, Ed
Beroset, Gilman Tolle, Robby Simpson, Colin O'Flynn and David Ryan Beroset, Gilman Tolle, Robby Simpson, Colin O'Flynn and David Ryan
for helpful comments and discussions that have shaped the document. for helpful comments and discussions that have shaped the document.
9. Changelog 9. Changelog
Changes from ietf-05 to ietf-06:
o Added improved text about the encoding of the format as UTF-8,
but treating it as binary data without normalization.
Changes from ietf-04 to ietf-05: Changes from ietf-04 to ietf-05:
o Removed mention of UTF-8 as this is already defined by RFC5988 o Removed mention of UTF-8 as this is already defined by RFC5988
(#158) (#158)
o Changed encoding considerations to "Binary data" (#157) o Changed encoding considerations to "Binary data" (#157)
o Updated ABNF to dissallow leading zeros in intergers (#159) o Updated ABNF to dissallow leading zeros in intergers (#159)
o Updated examples and reference for coap-06 (#152) o Updated examples and reference for coap-06 (#152)
skipping to change at page 18, line 39 skipping to change at page 18, line 47
10.1. Normative References 10.1. Normative References
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-06 (work in progress), May 2011. draft-ietf-core-coap-06 (work in progress), May 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
10.2. Informative References 10.2. Informative References
 End of changes. 10 change blocks. 
10 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/