draft-ietf-core-link-format-07.txt   draft-ietf-core-link-format-08.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track July 25, 2011 Intended status: Standards Track November 14, 2011
Expires: January 26, 2012 Expires: May 17, 2012
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-07 draft-ietf-core-link-format-08
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 January 26, 2012. This Internet-Draft will expire on May 17, 2012.
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 11, line 23 skipping to change at page 11, line 23
pattern. If the decoded query-pattern ends with "*", it is pattern. If the decoded query-pattern ends with "*", it is
sufficient that the remainder of the query-pattern be a prefix of the sufficient that the remainder of the query-pattern be a prefix of the
value denoted by the resource-param. A query-pattern of "*" will value denoted by the resource-param. A query-pattern of "*" will
match that resource-param with an empty string value. It is not match that resource-param with an empty string value. It is not
expected that very constrained nodes support filtering. 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 is Protocol (CoAP) that supports multicast requests, special care is
taken. A multicast request with a query string MUST not be responded taken. A multicast request with a query string MUST NOT be responded
to if filtering is not supported (to avoid a needless response to if filtering is not supported (to avoid a needless response
storm). storm).
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
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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-07 to ietf-08:
o IESG submission nits.
Changes from ietf-06 to ietf-07: Changes from ietf-06 to ietf-07:
o Moved the Content-type attribute (ct=) to the base CoAP o Moved the Content-type attribute (ct=) to the base CoAP
specification. specification.
Changes from ietf-05 to ietf-06: Changes from ietf-05 to ietf-06:
o Added improved text about the encoding of the format as UTF-8, o Added improved text about the encoding of the format as UTF-8,
but treating it as binary data without normalization. but treating it as binary data without normalization.
skipping to change at page 18, line 25 skipping to change at page 18, line 27
o Required support of wildcard * processing if filtering is o Required support of wildcard * processing if filtering is
supported. supported.
o Removed the aussumption of a default content-type assumption. o Removed the aussumption of a default content-type assumption.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-07 (work in progress), July 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 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 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
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000, <http:// Network-based Software Architectures", 2000, <http://
www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>. www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
 End of changes. 7 change blocks. 
10 lines changed or deleted 14 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/