draft-ietf-core-link-format-04.txt   draft-ietf-core-link-format-05.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft Sensinode Internet-Draft Sensinode
Intended status: Standards Track May 3, 2011 Intended status: Standards Track May 22, 2011
Expires: November 4, 2011 Expires: November 23, 2011
CoRE Link Format CoRE Link Format
draft-ietf-core-link-format-04 draft-ietf-core-link-format-05
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 4, 2011. This Internet-Draft will expire on November 23, 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 33 skipping to change at page 2, line 33
3.3. Content-type code 'ct' attribute . . . . . . . . . . . . . 9 3.3. Content-type code 'ct' attribute . . . . . . . . . . . . . 9
3.4. Maximum size estimate 'sz' attribute . . . . . . . . . . . 9 3.4. Maximum size estimate 'sz' attribute . . . . . . . . . . . 9
4. Well-known Interface . . . . . . . . . . . . . . . . . . . . . 10 4. Well-known Interface . . . . . . . . . . . . . . . . . . . . . 10
4.1. Query Filtering . . . . . . . . . . . . . . . . . . . . . 11 4.1. Query Filtering . . . . . . . . . . . . . . . . . . . . . 11
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
7.4. New CoAP Media Type registry entry . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . 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
skipping to change at page 4, line 32 skipping to change at page 4, line 32
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 appropraite REST interface descriptions along with
Resource Types to make discovery meaniningful. Resource Types to make discovery meaniningful.
1.2.1. Discovery 1.2.1. Discovery
In M2M application, for example home or building automation, there is In M2M applications, for example home or building automation, there
a need for local clients and servers to find and interact with each is a need for local clients and servers to find and interact with
other without human intervention. The CoRE Link Format can be used each other without human intervention. The CoRE Link Format can be
by servers in such environments to enable Resource Discovery of the used by servers in such environments to enable Resource Discovery of
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.
When a server's IP address is already known, either a priori or When a server's IP address is already known, either a priori or
resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast
discovery is performed in order to locate the entry point to the discovery is performed in order to locate the entry point to the
resource of interest. This is performed using a GET to /.well-known/ resource of interest. This is performed using a GET to /.well-known/
core on the server, which returns a payload in the CoRE Link Format. core on the server, which returns a payload in the CoRE Link Format.
A client would then match the appropriate Resource Type, Interface A client would then match the appropriate Resource Type, Interface
Description and possible Content-Type [RFC2045] for its application. Description and possible Content-Type [RFC2045] for its application.
These attributes may also be included in the query string in order to These attributes may also be included in the query string in order to
skipping to change at page 7, line 10 skipping to change at page 7, line 10
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 for
the CoRE Link Format (see Section 7.3). the CoRE Link Format (see Section 7.3).
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. The CoRE link format strings and URIs but do not end a description.
MUST use UTF-8 encoding [RFC3629], which SHOULD be in NFC (Unicode
Normalization Form C) as per Section 3 of [RFC5198].
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 26 skipping to change at page 8, line 26
The following CoRE specific target attributes are defined in addition The following CoRE specific target attributes are defined in addition
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.
; Import base format from Section 5 of 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 = ( "ct" "=" integer ) ; Range of 0-65535 link-extension = ( "ct" "=" cardinal ) ; Range of 0-65535
link-extension = ( "sz" "=" integer ) link-extension = ( "sz" "=" cardinal )
integer = 1*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
an ontology like an ontology like
skipping to change at page 9, line 19 skipping to change at page 9, line 19
used to interact with the target resource. One can think of this as used to interact with the target resource. One can think of this as
describing verbs usable on a resource. The interface description describing verbs usable on a resource. The interface description
attribute is meant to describe the generic REST interface to interact attribute is meant to describe the generic REST interface to interact
with a resource or a set of resources. It is expected that an with a resource or a set of resources. It is expected that an
interface description will be re-used by different resource types. interface description will be re-used by different resource types.
For example the resource types "OutdoorTemperature", "DewPoint" and For example the resource types "OutdoorTemperature", "DewPoint" and
"RelHumidity" could all be accessible using the interface description "RelHumidity" could all be accessible using the interface description
"http://www.example.org/myapp.wadl#sensor". "http://www.example.org/myapp.wadl#sensor".
The interface description could be for example the URI of a Web The interface description could be for example the URI of a Web
Application Description Language (WADL) [wadl] definition of the Application Description Language (WADL) [WADL] definition of the
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. Content-type code 'ct' attribute 3.3. Content-type code 'ct' attribute
The Content-type code "ct" attribute provides a hint about the The Content-type code "ct" attribute provides a hint about the
Internet media type this resource returns. Note that this is only a Internet media type this resource returns. Note that this is only a
hint, and does not override the Content-type Option of a CoAP hint, and does not override the Content-type Option of a CoAP
skipping to change at page 11, line 49 skipping to change at page 11, line 49
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
the example for readability. these examples for readability. Although the following examples use
CoAP response codes, the examples are applicable to HTTP as well (the
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: 200 OK RES: 2.05 "Content"
</sensors/temp>;ct=41;rt="TemperatureC";if="sensor", </sensors/temp>;ct=41;rt="TemperatureC";if="sensor",
</sensors/light>;ct=41;rt="LightLux";if="sensor" </sensors/light>;ct=41;rt="LightLux";if="sensor"
Without the linefeeds included for readability, the format actually Without the linefeeds included for readability, the format actually
looks as follows. looks as follows.
</sensors/temp>;ct=41;rt="TemperatureC";if="sensor",</sensors/light>; </sensors/temp>;ct=41;rt="TemperatureC";if="sensor",</sensors/light>;
ct=41;rt="LightLux";if="sensor" ct=41;rt="LightLux";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: 200 OK RES: 2.05 "Content"
</sensors>;rt="index";ct=40 </sensors>;rt="index";ct=40
REQ: GET /sensors REQ: GET /sensors
RES: 200 OK RES: 2.05 "Content"
</sensors/temp>;ct=41;rt="TemperatureC";if="sensor", </sensors/temp>;ct=41;rt="TemperatureC";if="sensor",
</sensors/light>;ct=41;rt="LightLux";if="sensor" </sensors/light>;ct=41;rt="LightLux";if="sensor"
An example query filter may look like: An example query filter may look like:
REQ: GET /.well-known/core?rt=LightLux REQ: GET /.well-known/core?rt=LightLux
RES: 200 OK 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: 200 OK RES: 2.05 "Content"
</sensors>;ct=40;rt="index";rt="Sensor Index", </sensors>;ct=40;rt="index";rt="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
RES: 200 OK 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 attibute. 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: 200 OK 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
Section 7 of [RFC5988]. The /.well-known/core resource may be Section 7 of [RFC5988]. The /.well-known/core resource may be
protected e.g. using DTLS when hosted on a CoAP server as per protected e.g. using DTLS when hosted on a CoAP server as per
[I-D.ietf-core-coap] Section 10.2. [I-D.ietf-core-coap] Section 10.2.
Multicast requests using CoAP for the well-known link-format Multicast requests using CoAP for the well-known link-format
skipping to change at page 15, line 13 skipping to change at page 15, line 13
format, application/link-format. format, application/link-format.
Type name: application Type name: application
Subtype name: link-format Subtype name: link-format
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: 8bit (UTF-8 (NFC)) Encoding considerations: Binary data
Security considerations: Security considerations:
Multicast requests using CoAP for the well-known link-format Multicast requests using CoAP for the well-known link-format
resources could be used to perform denial of service on a constrained resources could be used to perform denial of service on a constrained
network. A multicast request SHOULD only be accepted if the request network. A multicast request SHOULD only be accepted if the request
is sufficiently authenticated and secured using e.g. IPsec or an is sufficiently authenticated and secured using e.g. IPsec or an
appropriate object security mechanism. appropriate object security mechanism.
CoRE link format parsers should be aware that a link description may CoRE link format parsers should be aware that a link description may
skipping to change at page 16, line 5 skipping to change at page 16, line 5
Macintosh file type code(s): Macintosh file type code(s):
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: CoRE WG Author: CoRE WG
Change controller: IETF Change controller: IETF
7.4. New CoAP Media Type registry entry
This specification requests a value for application/link-format in
the CoAP Media Type Registry defined in [I-D.ietf-core-coap]. The
value "40" is requested as it has been in use by all existing
implementations of this specification.
8. Acknowledgments 8. Acknowledgments
Special thanks to Peter Bigot, who has made a considerable number Special thanks to Peter Bigot, who has made a considerable number
reviews and text contributions that greatly improved the document. reviews and text contributions that greatly improved the document.
In particular, Peter is responsible for the ABNF descriptions and the In particular, Peter is responsible for the ABNF descriptions and the
idea for a new "hosts" relation type. idea for a new "hosts" relation type.
Thanks to Mark Nottingham and Eran Hammer-Lahav for the discussions Thanks to Mark Nottingham and Eran Hammer-Lahav for the discussions
and ideas that led to this draft, and to Carsten Bormann, Martin and ideas that led to this draft, and to Carsten Bormann, Martin
Thomson, Alexey Melnikov and Peter Saint-Andre for extensive comments Thomson, Alexey Melnikov and Peter Saint-Andre for extensive comments
skipping to change at page 16, line 33 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-04 to ietf-05:
o Removed mention of UTF-8 as this is already defined by RFC5988
(#158)
o Changed encoding considerations to "Binary data" (#157)
o Updated ABNF to dissallow leading zeros in intergers (#159)
o Updated examples and reference for coap-06 (#152)
o Removed the applcation/link-format CoAP code registration, now
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).
o Added a range limitation for ct attribute. o Added a range limitation for ct attribute.
skipping to change at page 18, line 30 skipping to change at page 18, line 34
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] [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-04 (work in progress), January 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
[REST] Fielding, "Architectural Styles and the Design of Network- [REST] Fielding, R., "Architectural Styles and the Design of
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.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
skipping to change at page 19, line 26 skipping to change at page 19, line 27
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010. April 2010.
[wadl] Hadley, M., "Web Application Description Language (WADL)", [WADL] Hadley, M., "Web Application Description Language (WADL)",
2009, <http://java.net/projects/wadl/sources/svn/content/ 2009, <http://java.net/projects/wadl/sources/svn/content/
trunk/www/wadl20090202.pdf>. trunk/www/wadl20090202.pdf>.
Author's Address Author's Address
Zach Shelby Zach Shelby
Sensinode Sensinode
Kidekuja 2 Kidekuja 2
Vuokatti 88600 Vuokatti 88600
FINLAND FINLAND
 End of changes. 25 change blocks. 
45 lines changed or deleted 44 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/