draft-ietf-core-link-format-08.txt   draft-ietf-core-link-format-09.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track November 14, 2011 Intended status: Standards Track November 16, 2011
Expires: May 17, 2012 Expires: May 19, 2012
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-08 draft-ietf-core-link-format-09
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 May 17, 2012. This Internet-Draft will expire on May 19, 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 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . 18
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 memory) 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.
The discovery of resources hosted by a constrained server is very The discovery of resources hosted by a constrained server is very
important in machine-to-machine applications where there are no important in machine-to-machine applications where there are no
humans in the loop and static interfaces result in fragility. The humans in the loop and static interfaces result in fragility. The
discovery of resources provided by an HTTP [RFC2616] Web Server is discovery of resources provided by an HTTP [RFC2616] Web Server is
typically called Web Discovery and the description of relations typically called Web Discovery and the description of relations
between resources is called Web Linking [RFC5988]. In this document between resources is called Web Linking [RFC5988]. In the present
we refer to the discovery of resources hosted by a constrained web document we refer to the discovery of resources hosted by a
server, their attributes and other resource relations as CoRE constrained web server, their attributes and other resource relations
Resource Discovery. as CoRE Resource Discovery.
The main function of such a discovery mechanism is to provide The main function of such a discovery mechanism is to provide
Universal Resource Identifiers (URIs, called links) for the resources Universal Resource Identifiers (URIs, called links) for the resources
hosted by the server, complemented by attributes about those hosted by the server, complemented by attributes about those
resources and possible further link relations. In CoRE this resources and possible further link relations. In CoRE this
collection of links is carried as a resource of its own (as opposed collection of links is carried as a resource of its own (as opposed
to HTTP headers delivered with a specific resource). This document to HTTP headers delivered with a specific resource). This document
specifies a link format for use in CoRE Resource Discovery by specifies a link format for use in CoRE Resource Discovery by
extending the HTTP Link Header Format [RFC5988] to describe these extending the HTTP Link Header Format [RFC5988] to describe these
link descriptions. The CoRE Link Format is carried as a payload and link descriptions. The CoRE Link Format is carried as a payload and
skipping to change at page 4, line 27 skipping to change at page 4, line 27
Typical use cases for Web Linking on today's web include e.g. Typical use cases for Web Linking on today's web include e.g.
describing the author of a web page, or describing relations between describing the author of a web page, or describing relations between
web pages (next chapter, previous chapter etc.). Web Linking can web pages (next chapter, previous chapter etc.). Web Linking can
also be applied to M2M applications, where typed links are used to also be applied to M2M applications, where typed links are used to
assist a machine client in finding and understanding how to use assist a machine client in finding and understanding how to use
resources on a server. In this section a few use cases are described resources on a server. In this section a few use cases are described
for how the CoRE Link Format could be used in M2M applications. For for how the CoRE Link Format could be used in M2M applications. For
further technical examples see Section 5. As there are a large range further technical examples see Section 5. As there are a large range
of M2M applications, these use cases are purposely generic. This of M2M applications, these use cases are purposely generic. This
document assumes that different deployments or application domains document assumes that different deployments or application domains
will define the appropraite REST interface descriptions along with will define the appropriate REST interface descriptions along with
Resource Types to make discovery meaniningful. Resource Types to make discovery meaningful.
1.2.1. Discovery 1.2.1. Discovery
In M2M applications, for example home or building automation, there In M2M applications, for example home or building automation, there
is a need for local clients and servers to find and interact with is a need for local clients and servers to find and interact with
each other without human intervention. The CoRE Link Format can be each other without human intervention. The CoRE Link Format can be
used by servers in such environments to enable Resource Discovery of used by servers in such environments to enable Resource Discovery of
the resources hosted by the server. the resources hosted by the server.
Resource Discovery can be performed either unicast or multicast. Resource Discovery can be performed either unicast or multicast.
skipping to change at page 5, line 13 skipping to change at page 5, line 13
multicast. A GET request to the appropriate multicast address is multicast. A GET request to the appropriate multicast address is
made for /.well-known/core. In order to limit the number and size or made for /.well-known/core. In order to limit the number and size or
responses, a query string is recommended with the known attributes. responses, a query string is recommended with the known attributes.
Typically a resource would be discovered based on its Resource Type Typically a resource would be discovered based on its Resource Type
and/or Interface Description, along with possible application and/or Interface Description, along with possible application
specific attributes. specific attributes.
1.2.2. Resource Collections 1.2.2. Resource Collections
RESTful designs of M2M interfaces often make use of collections of RESTful designs of M2M interfaces often make use of collections of
resources. For example an index of temprature sensors on a data resources. For example an index of temperature sensors on a data
collection node or a list of alarms on a home security controller. collection node or a list of alarms on a home security controller.
The CoRE Link Format can be used to make it possible to find the The CoRE Link Format can be used to make it possible to find the
entry point to a collection and traverse its members. The entry entry point to a collection and traverse its members. The entry
point of a collection would always be included in /.well-known/core point of a collection would always be included in /.well-known/core
to enable its discovery. The members of the collection can be to enable its discovery. The members of the collection can be
defined either through the interface description of the resource defined either through the interface description of the resource
along with a parameter resource for the size of the collection, or by along with a parameter resource for the size of the collection, or by
using the link format to describe each resource in the collection. using the link format to describe each resource in the collection.
These links could be located under /.well-known/core or hosted for These links could be located under /.well-known/core or hosted for
example in the root resource of the collection. example in the root resource of the collection.
skipping to change at page 5, line 37 skipping to change at page 5, line 37
In many deployment scenarios, for example constrained networks with In many deployment scenarios, for example constrained networks with
sleeping servers, or large M2M deployments with bandwidth limited sleeping servers, or large M2M deployments with bandwidth limited
access networks, it makes sense to deploy resource directory entities access networks, it makes sense to deploy resource directory entities
which store links to resources stored on other servers. Think of which store links to resources stored on other servers. Think of
this as a limited search engine for constrained M2M resources. this as a limited search engine for constrained M2M resources.
The CoRE Link Format can be used by a server to register resources The CoRE Link Format can be used by a server to register resources
with a resource directory, or to allow a resource directory to poll with a resource directory, or to allow a resource directory to poll
for resources. Resource polling uses the same process as unicast or for resources. Resource polling uses the same process as unicast or
multicast discovery, however usually without filtering. Resource multicast discovery, however usually without filtering. Resource
registration can be achived by having each server POST their registration can be archived by having each server POST their
resources to /.well-known/core on the resource directory. This in resources to /.well-known/core on the resource directory. This in
turn adds links to the resource directory under an appropriate turn adds links to the resource directory under an appropriate
resource. These links can then be discovered by any client by a resource. These links can then be discovered by any client by a
performing a GET on the resource directory using a query string performing a GET on the resource directory using a query string
filter. filter.
1.3. Terminology 1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 6, line 17 skipping to change at page 6, line 17
A framework for indicating the relationships between web A framework for indicating the relationships between web
resources. resources.
Link Link
Also called "typed links" in RFC5988. A link is a typed Also called "typed links" in RFC5988. A link is a typed
connection between two resources identified by URIs. Made up of a connection between two resources identified by URIs. Made up of a
context URI, a link relation type, a target URI, and optional context URI, a link relation type, a target URI, and optional
target attributes. target attributes.
Link Format Link Format
A particular serialisation of typed links. A particular serialization of typed links.
CoRE Link Format CoRE Link Format
A particular serialization of typed links based the HTTP Link A particular serialization of typed links based the HTTP Link
Header serialization defined in Section 5 of RFC5988, but carried Header serialization defined in Section 5 of RFC5988, but carried
as a resource representation with a MIME type. as a resource representation with a MIME type.
Attribute Attribute
Properly called "Target Attribute" in RFC5988. A set of key/value Properly called "Target Attribute" in RFC5988. A set of key/value
pairs that descibe the link or its target. pairs that describe the link or its target.
CoRE Resource Discovery CoRE Resource Discovery
When a client discovers the list of resources hosted by a server, When a client discovers the list of resources hosted by a server,
their attributes and other link relations by accessing /.well- their attributes and other link relations by accessing /.well-
known/core. known/core.
2. Link Format 2. Link Format
The CoRE Link Format extends the HTTP Link Header format specified in The CoRE Link Format extends the HTTP Link Header format specified in
[RFC5988], which is specified in Augmented Backus-Naur Form (ABNF) [RFC5988]. The format does not require special XML or binary
notation [RFC5234]. The format does not require special XML or parsing, is fairly compact, and is extensible - all important
binary parsing, is fairly compact, and is extensible - all important
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 header. This specification thus defines the Internet media type
"application/link-format" for 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 Whereas the HTTP Link Header format depends on [RFC2616] for its
encoding, the CoRE Link Format is encoded as UTF-8 [RFC3629]. A encoding, the CoRE Link Format is encoded as UTF-8 [RFC3629]. A
decoder of the format is not expected to (but not prohibited from) 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 validate UTF-8 encoding and doesn't need to perform any UTF-8
normalization. UTF-8 data can be compared bit-wise, which allows normalization. UTF-8 data can be compared bit-wise, which allows
values to contain UTF-8 data without any added complexity for values to contain UTF-8 data without any added complexity for
constrained nodes. constrained nodes.
The CoRE link format uses the ABNF description and associated rules The CoRE link format is the [RFC5988] production named "Link", and
in Section 5 of [RFC5988]. In addition, the pchar rule is taken from imports the ABNF description and associated rules in Section 5 of
[RFC3986]. The "Link:" text is omitted as that is part of the HTTP that document. The "Link:" text is omitted as that is part of the
Link Header. As in [RFC5988], multiple link descriptions are HTTP Link Header. Note that the ABNF in the present document is
separated by commas. Note that commas can also occur in quoted compliant with [RFC5234]. As in [RFC5988], multiple link
strings and URIs but do not end a description. descriptions are separated by commas. Note that commas can also
occur in quoted strings and URIs but do not end a description.
2.1. Target and context URIs 2.1. Target and context URIs
Each link conveys one target URI as a URI-reference inside angle Each link conveys one target URI as a URI-reference inside angle
brackets ("<>"). The context URI of a link (also called base URI in brackets ("<>"). The context URI of a link (also called base URI in
[RFC3986]) conveyed in the CoRE Link Format is by default built from [RFC3986]) conveyed in the CoRE Link Format is by default built from
the scheme and authority parts of the target URI. In the absence of the scheme and authority parts of the target URI. In the absence of
this information in the target URI, the context URI is built from the this information in the target URI, the context URI is built from the
scheme and authority that was used for referencing the resource scheme and authority that was used for referencing the resource
returning the set of links, replacing the path with an empty path. returning the set of links, replacing the path with an empty path.
skipping to change at page 8, line 31 skipping to change at page 8, line 31
to the ABNF rules in Section 5 of [RFC5988]. These attributes to the ABNF rules in Section 5 of [RFC5988]. These attributes
describe information useful in accessing the target link of the describe information useful in accessing the target link of the
relation, and in some cases may be URIs. These URIs MUST be treated relation, and in some cases may be URIs. These URIs MUST be treated
as non resolvable identifiers (they are not meant to be retrieved). as non resolvable identifiers (they are not meant to be retrieved).
When attributes are compared, they MUST be compared as strings. When attributes are compared, they MUST be compared as strings.
Relationships to resources that are meant to be retrieved should be Relationships to resources that are meant to be retrieved should be
expressed as separate links using the anchor attribute and the expressed as separate links using the anchor attribute and the
appropriate relation type. appropriate relation type.
link-extension = <Defined in RFC5988> link-extension = <Defined in RFC5988>
link-extension = ( "rt" "=" quoted-string ) link-extension =/ ( "rt=" quoted-string )
link-extension = ( "if" "=" quoted-string ) link-extension =/ ( "if=" quoted-string )
link-extension = ( "sz" "=" cardinal ) link-extension =/ ( "sz=" cardinal )
cardinal = "0" / %x31-39 *DIGIT cardinal = "0" / %x31-39 *DIGIT
3.1. Resource type 'rt' attribute 3.1. Resource type 'rt' attribute
The resource type "rt" attribute is an opaque string used to assign a The resource type "rt" attribute is an opaque string used to assign a
semantically important type to a resource. One can think of this as semantically important type to a resource. One can think of this as
a noun describing the resource. In the case of a temperature a noun describing the resource. In the case of a temperature
resource this could be e.g. an application-specific semantic type resource this could be e.g. an application-specific semantic type
like "OutdoorTemperature", a Universal Resource Name (URN) like like "OutdoorTemperature", a Universal Resource Name (URN) like
"urn:temperature:outdoor" or a URI referencing a specific concept in "urn:temperature:outdoor" or a URI referencing a specific concept in
skipping to change at page 9, line 32 skipping to change at page 9, line 32
target resource "http://www.example.org/myapp.wadl#sensor", a URN target resource "http://www.example.org/myapp.wadl#sensor", a URN
indicating the type of interface to the resource "urn:myapp:sensor", indicating the type of interface to the resource "urn:myapp:sensor",
or an application-specific name "Sensor". Multiple interface or an application-specific name "Sensor". Multiple interface
description attributes MAY appear in a link. description attributes MAY appear in a link.
3.3. Maximum size estimate 'sz' attribute 3.3. Maximum size estimate 'sz' attribute
The maximum size estimate attribute "sz" gives an indication of the The maximum size estimate attribute "sz" gives an indication of the
maximum size of the resource indicated by the target URI. This maximum size of the resource indicated by the target URI. This
attribute is not expected to be included for small resources that can attribute is not expected to be included for small resources that can
comfortably by carried in a single Maxiumum Transmission Unit (MTU), comfortably by carried in a single Maximum Transmission Unit (MTU),
but SHOULD be included for resources larger than that. The maximum but SHOULD be included for resources larger than that. The maximum
size estimate attribute MUST NOT appear more than once in a link. size estimate attribute MUST NOT appear more than once in a link.
Note that there is no defined upper limit to the value of the sz Note that there is no defined upper limit to the value of the sz
attributes. Implementations MUST be prepared to accept large values. attributes. Implementations MUST be prepared to accept large values.
One implementation strategy is to convert any value larger than a One implementation strategy is to convert any value larger than a
reasonable size limit for this implementation to a special value reasonable size limit for this implementation to a special value
"Big", which in further processing would indicate that a size value "Big", which in further processing would indicate that a size value
was given that was so big that it cannot be processed by this was given that was so big that it cannot be processed by this
implementation. implementation.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
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.
filter-query = resource-param "=" query-pattern filter-query = resource-param "=" query-pattern
resource-param = "uri" | parmname resource-param = "uri" / parmname
query-pattern = 1*pchar [ "*" ] query-pattern = ptoken [ "*" ]
ptoken = <Defined in RFC5988>
The resource-param "uri" refers to the URI-reference between the "<" The resource-param "uri" refers to the URI-reference between the "<"
and ">" characters of a link. Other resource-param values refer to and ">" characters of a link. Other resource-param values refer to
the link attribute they name. Filtering is performed by comparing the link attribute they name. Filtering is performed by comparing
the query-pattern against the value of the attribute identified by the query-pattern against the value of the attribute identified by
the resource-param for each link-value in the collection of resources the resource-param for each link-value in the collection of resources
identified by the URI path. identified by the URI path.
If the decoded query-pattern does not end with "*", a link value 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 matches the query only if the value of the attribute or URI-reference
skipping to change at page 11, line 24 skipping to change at page 11, line 26
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 or if the filter does not match (to
storm). avoid a needless response 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
corresponding response code would be 200 OK). corresponding response code would be 200 OK).
skipping to change at page 13, line 9 skipping to change at page 13, line 9
RES: 2.05 "Content" RES: 2.05 "Content"
<http://www.example.com/sensors/temp123>;anchor="/sensors/temp" <http://www.example.com/sensors/temp123>;anchor="/sensors/temp"
;rel="describedby", ;rel="describedby",
</t>;anchor="/sensors/temp";rel="alternate" </t>;anchor="/sensors/temp";rel="alternate"
The following example shows a large firmware resource with a size The following example shows a large firmware resource with a size
attribute. The consumer of this link would use the sz attribute to attribute. The consumer of this link would use the sz attribute to
determine if the resource representation is too large and if block determine if the resource representation is too large and if block
transfer would be required to request it. In this case a client with transfer would be required to request it. In this case a client with
only a 64 KiB flash might only support a 16-bit integer for storing only a 64 KiB flash might only support a 16-bit integer for storing
the sz attibute. Thus a special flag or value should be used to the sz attribute. Thus a special flag or value should be used to
indicate "Big" (larger than 64 KiB). indicate "Big" (larger than 64 KiB).
REQ: GET /.well-known/core?rt=firmware REQ: GET /.well-known/core?rt=firmware
RES: 2.05 "Content" RES: 2.05 "Content"
</firmware/v2.1>;rt="firmware";sz=262144 </firmware/v2.1>;rt="firmware";sz=262144
6. Security Considerations 6. Security Considerations
This document needs the same security considerations as described in This document needs the same security considerations as described in
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-08 to ietf-09:
o Corrected ABNF and editorial nits.
o Elided empty responses to multicast request.
Changes from ietf-07 to ietf-08: Changes from ietf-07 to ietf-08:
o IESG submission nits. 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:
skipping to change at page 16, line 28 skipping to change at page 16, line 34
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.
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 disallow leading zeros in integers (#159)
o Updated examples and reference for coap-06 (#152) o Updated examples and reference for coap-06 (#152)
o Removed the applcation/link-format CoAP code registration, now o Removed the application/link-format CoAP code registration, now
included in the CoAP specification directly (#160) included in the CoAP specification directly (#160)
Changes from ietf-03 to ietf-04: Changes from ietf-03 to ietf-04:
o Removed the attribute registry (#145). o Removed the attribute registry (#145).
o Requested a CoAP media type for application/link-format (#144). o Requested a CoAP media type for application/link-format (#144).
o Editorial and reference improvements from AD review (#146). o Editorial and reference improvements from AD review (#146).
skipping to change at page 18, line 21 skipping to change at page 18, line 25
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
supported. supported.
o Removed the aussumption of a default content-type assumption. o Removed the assumption of a default content-type assumption.
10. References 10. References
10.1. Normative References 10.1. Normative References
[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.
 End of changes. 23 change blocks. 
39 lines changed or deleted 45 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/