draft-ietf-core-link-format-10.txt   draft-ietf-core-link-format-11.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track January 13, 2012 Intended status: Standards Track January 30, 2012
Expires: July 16, 2012 Expires: August 2, 2012
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-10 draft-ietf-core-link-format-11
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 July 16, 2012. This Internet-Draft will expire on August 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 10, line 48 skipping to change at page 10, line 48
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 (parmname is as
this only defines querying for a single parameter at a time. defined in [RFC5988], pct-encoded and unreserved are defined in
[RFC3986]). Note that this only defines querying for a single
parameter at a time.
filter-query = resource-param "=" query-pattern filter-query = resource-param "=" query-pattern
resource-param = "uri" / parmname resource-param = "uri" / parmname
query-pattern = search-token [ "*" ] query-pattern = search-token [ "*" ]
search-token = *search-char search-token = *search-char
search-char = unreserved / pct-encoded search-char = unreserved / pct-encoded
/ ":" / "@" ; from pchar / ":" / "@" ; from pchar
/ "/" / "?" ; from query / "/" / "?" ; from query
/ "!" / "$" / "'" / "(" / ")" / "!" / "$" / "'" / "(" / ")"
/ "+" / "," / ";" / "=" ; from sub-delims / "+" / "," / ";" / "=" ; from sub-delims
skipping to change at page 11, line 39 skipping to change at page 11, line 39
It is not expected that very constrained nodes support filtering. It is not expected that very constrained nodes support filtering.
Implementations not supporting filtering MUST simply ignore the query Implementations not supporting filtering MUST simply ignore the query
string and return the whole resource for unicast requests. string and return the whole resource for unicast requests.
When using a transfer protocol like the Constrained Application When using a transfer protocol like the Constrained Application
Protocol (CoAP) that supports multicast requests, special care needs Protocol (CoAP) that supports multicast requests, special care needs
to be taken. A multicast request with a query string SHOULD NOT be to be taken. A multicast request with a query string SHOULD NOT be
responded to if filtering is not supported or if the filter does not responded to if filtering is not supported or if the filter does not
match (to avoid a needless response storm). The exception is in match (to avoid a needless response storm). The exception is in
cases where the IP stack interface is not able to indicate that the cases where the IP stack interface is not able to indicate that the
source address was multicast. destination address was multicast.
5. Examples 5. Examples
A few examples of typical link descriptions in this format follows. A few examples of typical link descriptions in this format follows.
Multiple resource descriptions in a representation are separated by Multiple resource descriptions in a representation are separated by
commas. Linefeeds never occur in the actual format, but are shown in commas. Linefeeds never occur in the actual format, but are shown in
these examples for readability. Although the following examples use these examples for readability. Although the following examples use
CoAP response codes, the examples are applicable to HTTP as well (the CoAP response codes, the examples are applicable to HTTP as well (the
corresponding response code would be 200 OK). corresponding response code would be 200 OK).
This example includes links to two different sensors sharing the same This example includes links to two different sensors sharing the same
Interface Description. Interface Description.
REQ: GET /.well-known/core REQ: GET /.well-known/core
RES: 2.05 "Content" RES: 2.05 "Content"
</sensors/temp>;if="sensor", </sensors/temp>;if="sensor",
</sensors/light>;if="sensor" </sensors/light>;if="sensor"
Without the linefeeds included for readability, the format actually Without the linefeeds inserted here for readability, the format
looks as follows. actually looks as follows.
</sensors/temp>;if="sensor",</sensors/light>;if="sensor" </sensors/temp>;if="sensor",</sensors/light>;if="sensor"
This example arranges link descriptions hierarchically, with the This example arranges link descriptions hierarchically, with the
entry point including a link to a sub-resource containing links about entry point including a link to a sub-resource containing links about
the sensors. the sensors.
REQ: GET /.well-known/core REQ: GET /.well-known/core
RES: 2.05 "Content" RES: 2.05 "Content"
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-10 to ietf-11:
o Fixed editorial nits.
Changes from ietf-09 to ietf-10: Changes from ietf-09 to ietf-10:
o Changed to SHOULD NOT for multiple relation types (#178). o Changed to SHOULD NOT for multiple relation types (#178).
o Changed to SHOULD NOT for multicast response repression (#179). o Changed to SHOULD NOT for multicast response repression (#179).
o Updated ABNF for queries (#179). o Updated ABNF for queries (#179).
o Editorial improvements from WGLC comments. o Editorial improvements from WGLC comments.
 End of changes. 7 change blocks. 
9 lines changed or deleted 15 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/