draft-ietf-core-link-format-00.txt   draft-ietf-core-link-format-01.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track October 18, 2010 Intended status: Standards Track October 25, 2010
Expires: April 21, 2011 Expires: April 28, 2011
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-00 draft-ietf-core-link-format-01
Abstract Abstract
This document defines a link format for use by constrained CoAP web This document defines a link format for use by constrained CoAP web
servers to describe URIs of resources offered along with other servers to describe URIs of resources offered along with other
attributes. Based on the HTTP Link Header format, the CoRE link attributes. Based on the HTTP Link Header format, the CoRE link
format is carried as a payload and is assigned an Internet media format is carried as a payload and is assigned an Internet media
type. A well-known URI is defined as a default entry-point for type. A well-known URI is defined as a default entry-point for
requesting the list of links to resources hosted by a server. requesting the list of links to resources hosted by a server.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 April 21, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Link Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Link Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Target and context IRIs . . . . . . . . . . . . . . . . . 4 2.1. Target and context URIs . . . . . . . . . . . . . . . . . 4
2.2. Link relation 'rel' usage . . . . . . . . . . . . . . . . 5 2.2. Link relation 'rel' usage . . . . . . . . . . . . . . . . 5
2.3. Description 'd' usage . . . . . . . . . . . . . . . . . . 5 2.3. Description 'd' usage . . . . . . . . . . . . . . . . . . 5
2.4. Alternative URI 'sh' usage . . . . . . . . . . . . . . . . 5 2.4. Alternative URI 'sh' usage . . . . . . . . . . . . . . . . 5
2.5. Resource name 'n' usage . . . . . . . . . . . . . . . . . 5 2.5. Resource name 'n' usage . . . . . . . . . . . . . . . . . 5
2.6. Content-type code 'ct' usage . . . . . . . . . . . . . . . 5 2.6. Content-type code 'ct' usage . . . . . . . . . . . . . . . 5
2.7. Resource identifier 'id' usage . . . . . . . . . . . . . . 6 2.7. Resource identifier 'id' usage . . . . . . . . . . . . . . 6
2.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Well-known Interface . . . . . . . . . . . . . . . . . . . . . 6 3. Well-known Interface . . . . . . . . . . . . . . . . . . . . . 6
3.1. Query Filtering . . . . . . . . . . . . . . . . . . . . . 7 3.1. Query Filtering . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Well-known 'core' URI . . . . . . . . . . . . . . . . . . 8 5.1. Well-known 'core' URI . . . . . . . . . . . . . . . . . . 9
5.2. New link-format Internet media type . . . . . . . . . . . 8 5.2. New link-format Internet media type . . . . . . . . . . . 9
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Constrained RESTful Environments (CoRE) working group aims at The Constrained RESTful Environments (CoRE) working group aims at
realizing the REST architecture in a suitable form for the most realizing the REST architecture in a suitable form for the most
constrained nodes (e.g. 8-bit microcontrollers with limited RAM and constrained nodes (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-
machine (M2M) applications such as smart energy and building machine (M2M) applications such as smart energy and building
automation [I-D.shelby-core-coap-req]. automation [I-D.shelby-core-coap-req].
skipping to change at page 3, line 41 skipping to change at page 3, line 41
[I-D.nottingham-http-link-header] to describe resources hosted by a [I-D.nottingham-http-link-header] to describe resources hosted by a
constrained server. The CoRE link-format is carried as a payload and constrained server. The CoRE link-format is carried as a payload and
is assigned an Internet media type. A well-known URI "/.well-known/ is assigned an Internet media type. A well-known URI "/.well-known/
core" is defined as a default entry-point for requesting the list of core" is defined as a default entry-point for requesting the list of
links to resources hosted by a server. links to resources hosted by a server.
2. Link Format 2. Link Format
CoRE resource discovery extends the HTTP Link Header format specified CoRE resource discovery extends the HTTP Link Header format specified
in [I-D.nottingham-http-link-header] which is specified in Augmented in [I-D.nottingham-http-link-header] which is specified in Augmented
Backus-Naur Form (ABNF) notation [RFC5234]. The format does not Backus-Naur Form (ABNF) notation [RFC2616]. The format does not
require special XML or binary parsing, and is extensible. require special XML or binary parsing, and is extensible.
This link format is used for a similar purpose to that described in This link format is used for a similar purpose to that described in
[I-D.nottingham-http-link-header], to describe one or more [I-D.nottingham-http-link-header], to describe one or more
relationships between resources. However in this specification the relationships between resources. However in this specification the
link format is extended with specific constrained M2M link link format is extended with specific constrained M2M link
parameters, links are carried as a payload rather than in a message parameters, links are carried as a payload rather than in a message
header, and a default interface is defined to discover resources header, and a default interface is defined to discover resources
described by these links. described by these links.
[I-D.nottingham-http-link-header] did not require an Internet media [I-D.nottingham-http-link-header] did not require an Internet media
type for this link format, as it assumes to be carried in an HTTP type for this link format, as it assumes to be carried in an HTTP
header. This specification thus requests a Internet media type for header. This specification thus requests a Internet media type for
this format (see Section 5.2). this format (see Section 5.2).
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 [I-D.nottingham-http-link-header]. The "Link:" text in Section 5 of [I-D.nottingham-http-link-header]. In addition, the
is omitted as that is part of the HTTP Link Header. Multiple link URI, URI-reference and pchar rules are taken from [RFC3986]. The
descriptions are separated by commas. The CoRE link format MUST use "Link:" text is omitted as that is part of the HTTP Link Header.
the US-ASCII character set (support for RFC2231 encoding of non-ASCII Multiple link descriptions are separated by commas. The CoRE link
content TBD). The following CoRE specific link-extension parameters format MUST use the US-ASCII character set (support for RFC2231
to the format are defined: encoding of non-ASCII content TBD). The following CoRE specific
link-extension parameters to the format are defined:
link-extension = ( "d" "=" <"> URI <">) link-extension = ( "d" "=" <"> URI-reference <">)
link-extension = ( "sh" "=" <"> URI-Reference <">) link-extension = ( "sh" "=" <"> URI-reference <">)
link-extension = ( "n" "=" ( quoted-string | URI ) ) link-extension = ( "n" "=" quoted-string )
link-extension = ( "ct" "=" integer ) link-extension = ( "ct" "=" integer )
link-extension = ( "id" "=" ( quoted-string | URI ) ) link-extension = ( "id" "=" quoted-string )
integer = 1*DIGIT integer = 1*DIGIT
2.1. Target and context IRIs 2.1. Target and context URIs
Each link description conveys one target URI as a URI-Reference Each link description conveys one target URI as a URI-reference
inside angle brackets ("<>"). The context of a link conveyed in the inside angle brackets ("<>"). The context URI of a link (also called
description is by default the URI of the resource that returned the base URI in [RFC3986]) conveyed in the description is by default the
link-format representation (usually ./well-known/core). Thus each URI of the resource that returned the link-format representation.
link can be thought of as describing a target resource hosted by the Thus each link can be thought of as describing a target resource
server in the absence of further relation information. This is an hosted by the server in the absence of further relation information.
important difference to the way the HTTP Link Header format is used, This is an important difference to the way the HTTP Link Header
as it is included in the header of an HTTP response for some URI format is used, as it is included in the header of an HTTP response
(this URI is by default the context). Thus the HTTP Link Header is for some URI (this URI is by default the context). Thus the HTTP
by default relating the target URI to the URI that was requested. In Link Header is by default relating the target URI to the URI that was
comparison, the CoRE link format includes one or more link entries, requested. In comparison, the CoRE link format includes one or more
each describing a resource hosted by a server. link entries, each describing a resource hosted by a server. See
Section 5 of [RFC3986] for a description of how URIs are constructed
from URI references.
As per Section 5.2 of [I-D.nottingham-http-link-header] a link As per Section 5.2 of [I-D.nottingham-http-link-header] a link
description MAY include an "anchor" attribute, in which case the description MAY include an "anchor" attribute, in which case the
context is the URI included in that attribute. This can be used to context is the URI included in that attribute. This can be used to
describe a relationship between two resources. A consuming describe a relationship between two resources. A consuming
implementation can however choose to ignore such links. It is not implementation can however choose to ignore such links. It is not
expected that most implementations will be able to derive useful from expected that most implementations will be able to derive useful
explicitly anchored links. information from explicitly anchored links.
2.2. Link relation 'rel' usage 2.2. Link relation 'rel' usage
Link descriptions in CoRE are typically used to describe entry points Link descriptions in CoRE are typically used to describe entry points
to services hosted by the server, and thus in the absence of the rel to services hosted by the server, and thus in the absence of the rel
attribute the registered "service" relation type is assumed. In the attribute the registered "service" relation type is assumed. In the
CoRE link format the service relation type indicates that the link is CoRE link format the service relation type indicates that the link is
a service hosted by the server (in the absence of the anchor a service hosted by the server (in the absence of the anchor
attribute). A description can make use of any registered relation attribute). A description can make use of any registered relation
type or extension types in the form of a URI by including the rel type or extension types in the form of a URI by including the rel
skipping to change at page 5, line 31 skipping to change at page 5, line 31
Multiple description attributes MAY appear in a link description. Multiple description attributes MAY appear in a link description.
2.4. Alternative URI 'sh' usage 2.4. Alternative URI 'sh' usage
This attribute can be included to define an alternative short URI This attribute can be included to define an alternative short URI
which can also be used to access the target resource. Multiple which can also be used to access the target resource. Multiple
alternative short URI attributes MAY appear in a link description. alternative short URI attributes MAY appear in a link description.
2.5. Resource name 'n' usage 2.5. Resource name 'n' usage
The resource name "n" attribute is used to assign eith a human The resource name "n" attribute is used to assign either a human
readable or a semantically important name to a resource. In the case readable or a semantically important name to a resource. In the case
of a temperature sensor resource the name could be something like of a temperature sensor resource the name could be something like
"Temperature in Centigrade", a URI to an ontology like "Temperature in Centigrade", a URI to an ontology like
"http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature" or an "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature" or an
application-specific semantic name like "TemperatureC". Multiple application-specific semantic name like "TemperatureC". Multiple
name attributes MAY appear in a link description. name attributes MAY appear in a link description.
2.6. Content-type code 'ct' usage 2.6. Content-type code 'ct' usage
The Content-type code "ct" attribute provides a hint about the The Content-type code "ct" attribute provides a hint about the
skipping to change at page 6, line 48 skipping to change at page 6, line 48
GET /.well-known/core/sensors GET /.well-known/core/sensors
</sensors/temp>;sh="/t";n="TemperatureC", </sensors/temp>;sh="/t";n="TemperatureC",
</sensors/light>;sh="/l";ct=41;n="LightLux" </sensors/light>;sh="/l";ct=41;n="LightLux"
3. Well-known Interface 3. Well-known Interface
Resource discovery in CoRE is accomplished through the use of a well- Resource discovery in CoRE is accomplished through the use of a well-
known resource URI which returns a list of links (resource known resource URI which returns a list of links (resource
descriptions) offered by that constrained server. Well-known descriptions) offered by that constrained server. Well-known
resources have a reserved base URI "/.well-known/" as specified in resources have a path component that begins with "/.well-known/" as
[RFC5785]. This document defines a new well-known URI for CoRE specified in [RFC5785]. This document defines a new well-known path
discovery "/.well-known/core" Section 5.1. A server implementing prefix for CoRE discovery "/.well-known/core" [Section 5.1]. A
this specification MUST support this URI on the default port server implementing this specification MUST support this path prefix
appropriate for the protocol for the purpose of resource discovery. on the default port appropriate for the protocol for the purpose of
It is however up to the application which link descriptions are resource discovery. It is however up to the application which link
included and how they are organized. In the absense of any links, a descriptions are included and how they are organized. In the absense
zero-length payload is returned. The resource representation of this of any links, a zero-length payload is returned. The resource
resource is described in Section 2. representation of this resource is described in Section 2.
The CoRE resource discovery interface supports the following The CoRE resource discovery interface supports the following
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 list of link descriptions available from a CoAP server (if any). a list of link descriptions available from a CoAP server (if any).
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 3.1. For example using a query string as specified in Section 3.1. For example
[GET /.well-known/core?n=TemperatureC] would request resources [GET /.well-known/core?n=TemperatureC] would request resources
skipping to change at page 7, line 41 skipping to change at page 7, line 41
End-points with a large number of resources SHOULD include resource End-points with a large number of resources SHOULD include resource
descriptions only for important services or collections and organize descriptions only for important services or collections and organize
their resource descriptions into a hierarchy of link resources. This their resource descriptions into a hierarchy of link resources. This
is done by including links in the /.well-known/core list which point is done by including links in the /.well-known/core list which point
to other resource lists, e.g. </.well-known/core/sensors>. Such a to other resource lists, e.g. </.well-known/core/sensors>. Such a
hierarchy SHOULD be under the /.well-known/core path but could be hierarchy SHOULD be under the /.well-known/core path but could be
located elsewhere. located elsewhere.
3.1. Query Filtering 3.1. Query Filtering
A server implementing this document MAY support the query string A server implementing this document MAY recognize the query part of a
/.well-known/core? with uri= corresponding to the link-value or any resource-discovery URI as a filter on the resources to be returned.
of the resource description attributes for the purpose of filtering a The query part should conform to the following syntax:
discovery. It is not expected that very constrained nodes support
filtering. Implementations not supporting filtering MUST simply filter-query = resource-param "=" query-pattern
ignore the query string and return the whole resource. An exact resource-param = "uri" | "d" | "sh" | "n" | "id"
query-pattern = 1*pchar [ "*" ]
The resource-param "uri" refers to the URI-reference between the "<"
and ">" characters of a link-value. Other resource-param values
refer to the link attribute they name. (TBD: Do we want to add the
resource description attributes that I excluded, or the standard
link-param attributes from I-D.nottingham-http-link-header?)
Filtering is performed by comparing the query-pattern against the
value of the attribute identified by the resource-param for each
link-value in the collection of resources identified by the URI path.
If the decoded query-pattern does not end with "*", a link value
matches the query only if the value of the attribute or URI-reference
denoted by the resource-param is bytewise identical to the query-
pattern. If the decoded query-pattern ends with "*", it is
sufficient that the remainder of the query-pattern be a prefix of the
value denoted by the resource-param.
It is not expected that very constrained nodes support filtering.
Implementations not supporting filtering MUST simply ignore the query
string and return the whole resource for unicast requests. An exact
match is performed on the query string, and a 200 OK response is match is performed on the query string, and a 200 OK response is
returned with link descriptions that contains the matching entries returned with link descriptions that contains the matching entries
(if any). Implementations supporting filtering MUST also support (if any). In contrast, a multicast request with a query string MUST
wildcard * endings. If resource descriptions are organized not be responded to if filtering is not supported (to avoid a
needless response storm). If resource descriptions are organized
hierarchically, a query on the root resource /.well-known/core SHOULD hierarchically, a query on the root resource /.well-known/core SHOULD
return all matching resource descriptions from the entire hierarchy. return all matching resource descriptions from the entire hierarchy.
An example query on the link descriptions from Section 2 may look An example query on the link descriptions from Section 2 may look
like: like:
GET /.well-known/core?n=LightLux GET /.well-known/core?n=LightLux
</sensors/light>;sh="/l";ct=41;n="LightLux" </sensors/light>;sh="/l";ct=41;n="LightLux"
4. Security Considerations 4. Security Considerations
This document needs the same security considerations as described in This document needs the same security considerations as described in
Section 7 of [I-D.nottingham-http-link-header]. The /.well-known/ Section 7 of [I-D.nottingham-http-link-header]. The /.well-known/
core resource may be protected e.g. using DTLS when hosted on a CoAP core resource may be protected e.g. using DTLS when hosted on a CoAP
server as per [I-D.ietf-core-coap] Section 10.2. server as per [I-D.ietf-core-coap] Section 10.2.
Great care must be taken when processing multicast requests using
CoAP for the well-known link-format resources, as this could be used
to perform denial of service on a constrained network. A multicast
request SHOULD only be accepted if the request is sufficiently
authenticated and secured.
5. IANA Considerations 5. IANA Considerations
5.1. Well-known 'core' URI 5.1. Well-known 'core' URI
This memo registers the "core" well-known URI in the Well-Known URI This memo registers the "core" well-known URI in the Well-Known URI
Registry as defined by [RFC5785]. Registry as defined by [RFC5785].
URI suffix: core URI suffix: core
Change controller: IETF Change controller: IETF
skipping to change at page 9, line 33 skipping to change at page 10, line 17
Restrictions on usage: None Restrictions on usage: None
Author: CoRE WG Author: CoRE WG
Change controller: IETF Change controller: IETF
6. Acknowledgments 6. Acknowledgments
Special thanks to Mark Nottingham and Eran Hammer-Lahav for Special thanks to Mark Nottingham and Eran Hammer-Lahav for
discussions and ideas that led to this draft, and to Carsten Bormann discussions and ideas that led to this draft, and to Carsten Bormann
for extensive comments and contributions that improved the text. and Peter Bigot for extensive comments and contributions that
improved the text.
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, Peter Bigot, Colin O'Flynn and Beroset, Gilman Tolle, Robby Simpson, Peter Bigot, Colin O'Flynn and
David Ryan for helpful comments and discussions that have shaped the David Ryan for helpful comments and discussions that have shaped the
document. document.
7. Changelog 7. Changelog
Changes from ietf-00 to ietf-01:
o Editorial changes to correct references.
o Formal definition for filter query string.
o Removed URI-reference option from "n" and "id".
o Added security text about multicast requests.
Changes from shelby-00 to ietf-00: Changes from shelby-00 to ietf-00:
o Fixed the ABNF link-extension definitions (quotes around URIs, o Fixed the ABNF link-extension definitions (quotes around URIs,
integer definition). integer definition).
o Clarified that filtering is optional, and the query string is to o Clarified that filtering is optional, and the query string is to
be ignored if not supported (and the URL path processed as be ignored if not supported (and the URL path processed as
normally). normally).
o Required support of wildcard * processing if filtering is o Required support of wildcard * processing if filtering is
skipping to change at page 10, line 28 skipping to change at page 11, line 21
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Frank, B., and D. Sturek, "Constrained Shelby, Z., Frank, B., and D. Sturek, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-02 Application Protocol (CoAP)", draft-ietf-core-coap-02
(work in progress), September 2010. (work in progress), September 2010.
[I-D.nottingham-http-link-header] [I-D.nottingham-http-link-header]
Nottingham, M., "Web Linking", Nottingham, M., "Web Linking",
draft-nottingham-http-link-header-10 (work in progress), draft-nottingham-http-link-header-10 (work in progress),
May 2010. May 2010.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Specifications: ABNF", STD 68, RFC 5234, January 2008. Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Uniform Resource Identifiers (URIs)", RFC 5785, Resource Identifier (URI): Generic Syntax", STD 66,
April 2010. RFC 3986, January 2005.
8.2. Informative References 8.2. Informative References
[I-D.shelby-core-coap-req] [I-D.shelby-core-coap-req]
Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R.
Kelsey, "CoAP Requirements and Features", Kelsey, "CoAP Requirements and Features",
draft-shelby-core-coap-req-02 (work in progress), draft-shelby-core-coap-req-02 (work in progress),
October 2010. October 2010.
Author's Address Author's Address
 End of changes. 21 change blocks. 
64 lines changed or deleted 107 lines changed or added

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