One document matched: draft-greevenbosch-core-profile-description-00.txt
core B. Greevenbosch
Internet-Draft Huawei Technologies
Intended status: Informational June 12, 2012
Expires: December 14, 2012
CoAP Profile Description Format
draft-greevenbosch-core-profile-description-00
Abstract
This document provides a profile description format, that can be used
to express capabilities of a CoAP server.
Greevenbosch Expires December 14, 2012 [Page 1]
Internet-Draft CoAP Profile Description Format June 2012
Note
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Greevenbosch Expires December 14, 2012 [Page 2]
Internet-Draft CoAP Profile Description Format June 2012
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Profile Interface . . . . . . . . . . . . . . . . . . . . 6
4. The Profile Format . . . . . . . . . . . . . . . . . . . . . . 7
4.1. The Options "op" profile field . . . . . . . . . . . . . . 7
4.2. The Media-Types "mt" profile field . . . . . . . . . . . . 7
5. Usage with servers, resources and batches . . . . . . . . . . 8
6. Forward compatibility . . . . . . . . . . . . . . . . . . . . 9
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Open topics . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Greevenbosch Expires December 14, 2012 [Page 3]
Internet-Draft CoAP Profile Description Format June 2012
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Greevenbosch Expires December 14, 2012 [Page 4]
Internet-Draft CoAP Profile Description Format June 2012
2. Introduction
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
RESTful protocol for constrained nodes and networks.
Often, a client first learns about a resource through the link format
[I-D.ietf-core-link-format]. The link format only provides basic
information, for example the resource URL. However, it would be good
if the client could get more extensive information on the resources
when required. This document defines a profile description format,
which can be used to signal several parameters about resources and
their servers.
One of the main features of the CoAP protocol is the ability to
include CoAP options. These options can be either elective or
critical. A message with an unsupported critical option will be
rejected, whereas unsupported elective options will be ignored.
Even though it is well defined how the server must respond to
unsupported options, it is useful for the client to know which
options are supported in advance. In this way, it can determine
which options are viable to use in a transaction, and which features
cannot be exploited. This specification allows signalling of the
supported options by the resource.
Another important feature of a server is which media types it
supports. This document allows signalling of that information too.
It is anticipated that more profile descriptions will become
available in the future.
Greevenbosch Expires December 14, 2012 [Page 5]
Internet-Draft CoAP Profile Description Format June 2012
3. The Profile Interface
The profile description can be obtained through a link with interface
type "core#p" (see also [I-D.shelby-core-interfaces]). The URI of
the profile description should be equal to the URI of the associated
resource, but with a "/p" suffix. For example, if the client wants
to get profile description on a server witn URI "www.example.org", it
can send a GET request for "coap://www.example.org/p".
If the profile of a particular resource is available, it should use
the same naming convention. For example, the profile of the sensor
"coap://www.example.org/s/tmp" (on the same server) can be acquired
with a GET to: "coap://www.example.org/s/tmp/p".
Greevenbosch Expires December 14, 2012 [Page 6]
Internet-Draft CoAP Profile Description Format June 2012
4. The Profile Format
The profile description is formatted as a JSON document. It consists
of several profile fields, each of which has associated parameters.
4.1. The Options "op" profile field
The Options "op" profile field contains a list of options that are
supported by a resource. It has the format depicted in Figure 1,
where op1, op2, ... are integers representing the option numbers of
the supported options, as defined in [I-D.ietf-core-coap] and/or
through IANA. The option numbers MUST appear in numerical order,
starting with the lowest number.
"op":[op1,op2,...]
Figure 1: "op" syntax
When including the "op" profile field in the profile description of a
resource, all option numbers of the CoAP options supported by that
resource MUST be included. Options that are not supported by the
resource MUST NOT be included in the "op" profile field.
If the "op" profile field is available, the receiving party SHALL
assume a non-listed option is not supported by the associated
resource.
4.2. The Media-Types "mt" profile field
The Media-Types "mt" profile field indicates which media-types are
supported. It has the format depicted in Figure 2, where mt1, mt2,
... are integers representing the media-type numbers of the supported
media-types, as defined in [I-D.ietf-core-coap] and/or through IANA.
The media-type numbers MUST appear in numerical order, starting with
the lowest number.
"mt":[mt1,mt2,...]
Figure 2: "mt" syntax
When including the "mt" profile field in the profile description of a
resource, all media-types of the CoAP options supported by that
resource MUST be included. Media-types that are not supported by the
resource MUST NOT be included in the "mt" profile field.
If the "mt" profile field is available, the receiving party SHALL
assume a non-listed media-type is not supported by the associated
resource.
Greevenbosch Expires December 14, 2012 [Page 7]
Internet-Draft CoAP Profile Description Format June 2012
5. Usage with servers, resources and batches
A CoAP server may cater for multiple resources. In addition, the
document [I-D.shelby-core-interfaces] provides a batch mechanism that
allows querying/manipulating multiple resources at once.
The "/p" URI suffix allows obtaining profile description on each of
these three levels. For example, a GET to "http://www.example.org/p"
would return profile description about the complete server, whereas a
GET to "http://www.example.org/s/tmp/p" only returns profile
description about the temperature sensor "tmp". Lastly, a GET to
"http://www.example.org/s/p", where "/s" is a batch of sensors, would
return common profile description for all these sensors.
The hierarchical nature of these three entities implies that profiles
can only become more restrictive when going to a lower level. For
example, a server may support the block option, whereas one of its
resources does not. In that case, the profile of the server would
indicate block option support, whereas the profile of the resource
would not do so.
Greevenbosch Expires December 14, 2012 [Page 8]
Internet-Draft CoAP Profile Description Format June 2012
6. Forward compatibility
To allow addition of new profile fields in the future, unknown
profile fields SHOULD be ignored by the client.
Greevenbosch Expires December 14, 2012 [Page 9]
Internet-Draft CoAP Profile Description Format June 2012
7. Examples
The following is an example of a camera sensor at
"coap://www.example.org/s/cam", that supports the "Content-Type" (1),
"Proxy-Uri" (3), "ETag" (4), "Uri-Host" (5), "Uri-Port" (7), "Uri-
Path" (9), "Token" (11) and "Block2" (17) options.
The supported media types are "text/plan" (0), "application/
link-format" (40) and "application/json" (50).
Req: GET /s/cam/p
Res: 2.05 Content (application/json)
{
"op":[1,3,4,5,7,9,11,17],
"mt":[0,40,50]
}
Greevenbosch Expires December 14, 2012 [Page 10]
Internet-Draft CoAP Profile Description Format June 2012
8. Open topics
o How to signal the client profile?
o Which other profile data needs signalling?
o A natural media type for a camera would be JPEG. Therefore the
"image/jpeg" media type may need CoAP registration.
o Currently, support of observe can be signalled in the link format
as well as through the mechanism described here.
o Section 5 describes the hierchical nature of servers, batches and
sensors, and how the profiles fit in this hierarchy. It is the
question how to handle sensors that do not provide profile data.
One option could be to assume profile description is inherited,
unless separately specified. This may be reasonable as often the
server provides most functionality to all of its resources.
However, if we don't allow inheritance of the profile description,
it would be needed to specify the profile description for all
resources separately.
o Is it needed to signal the profile description on a resource
basis, or would it be enough to have only one, associated with the
server?
o Fix the order in which the profile fields must appear?
o Make a distinction between "critical" and "elective" profile
fields?
Greevenbosch Expires December 14, 2012 [Page 11]
Internet-Draft CoAP Profile Description Format June 2012
9. Security Considerations
For general CoAP security considerations see [I-D.ietf-core-coap].
In an unprotected environment, an attacker can change the profile
description. For example, the list of supported options may be
changed. This could cause the client to make a wrong decision on
which mechanisms to use. However, such a threat is normal in
environments that lack secure authentication.
Greevenbosch Expires December 14, 2012 [Page 12]
Internet-Draft CoAP Profile Description Format June 2012
10. IANA Considerations
o A registry for profile fields as well as possible values needs to
be set up.
o The "core#p" interface must be registered in due time.
Greevenbosch Expires December 14, 2012 [Page 13]
Internet-Draft CoAP Profile Description Format June 2012
11. Acknowledgements
The author would like to thank Kepeng Li for his ideas and feedback.
Greevenbosch Expires December 14, 2012 [Page 14]
Internet-Draft CoAP Profile Description Format June 2012
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-09 (work in progress), March 2012.
[I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-12 (work in progress),
May 2012.
[I-D.shelby-core-interfaces]
Shelby, Z., "CoRE Link Format",
draft-shelby-core-interfaces-02 (work in progress),
March 2012.
Greevenbosch Expires December 14, 2012 [Page 15]
Internet-Draft CoAP Profile Description Format June 2012
Author's Address
Bert Greevenbosch
Huawei Technologies Co., Ltd.
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone: +86-755-28978088
Email: bert.greevenbosch@huawei.com
Greevenbosch Expires December 14, 2012 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 20:15:42 |