Internet DRAFT - draft-softgear-core-coapa
draft-softgear-core-coapa
CoRE Working Group Seok-Kap Ko
Internet-Draft Ilkyun Park
Intended status: Standard Track Seung-Hun Oh
Expires: January 14, 2014 Byung-Tak Lee
ETRI
July 14, 2013
ASCII Encoding for Constrained Application Protocol (CoAP/A)
draft-softgear-core-coapa-00.txt
Abstract
This document defines ASCII encoding method for Constrained
Application Protocol(CoAP). CoAP has defined a binary encoding method
to exchange requests and responses between constrained nodes or
gateways. However, some communication modules in constrained nodes
support ASCII data only. These modules are cheaper and widely
deployed. To support these modules, this document describes the
method to convert binary CoAP messages to base64 styled ASCII
messages.
Status of this Memo
This Internet-Draft is submitted to IETF 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 January 14, 2014.
Copyright Notice
Copyright (c) 2013 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
Seokkap, et al. Expires January 14, 2014 [Page 1]
Internet-Draft CoAP/A July 2013
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.
Seokkap, et al. Expires January 14, 2014 [Page 2]
Internet-Draft CoAP/A July 2013
Table of Contents
1. Introduction ................................................ 4
2. Terminology ................................................. 4
3. Base64 encoding for CoAP .................................... 5
3.1. Overview ............................................... 5
3.2. Examples ............................................... 6
4. Security Considerations ..................................... 7
5. IANA Considerations ......................................... 7
6. Acknowledgments ............................................. 8
7. References .................................................. 8
7.1. Normative References ................................... 8
Seokkap, et al. Expires January 14, 2014 [Page 3]
Internet-Draft CoAP/A July 2013
1. Introduction
The Constrained Application Protocol (CoAP) is a specialized web
transfer protocol for use with constrained nodes and constrained
networks. Current CoAP draft document [COAP] describes a binary
encoding method for exchanging requests and response between nodes.
Binary encoding is compact and fast. However, in real deployment
environment, many constrained nodes use ASCII encoding only. Many
ZigBee communication modules and WiFi communication modules for
embedded devices allow ASCII characters only. Some modules can send a
limited size (about 50 bytes) message at a time. Because these
communication modules are cheaper and widely deployed, ASCII version
of CoAP is required.
To support ASCII encoding, an approach to design new encoding method
may be inefficient. Therefore, this document reuses Base64
encoding/decoding. Binary CoAP messages are converted to ASCII
messages before transmission. ASCII encoded messages are converted to
binary CoAP messages again after receiving via communication channel.
This document replaces some characters in the standard Base64
character set because of escape characters, for example, "+"
character. To support fragmentation and reassembly if a communication
module allows small size of message for transmitting or receiving,
this document adds "#" character at end of the each messages.
Because Base64 encoding/decoding logic is very simple, it requires
just small code size for it. The code for it could be written with
about 120 lines source code.
2. Terminology
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 RFC 2119 [RFC2119].
Seokkap, et al. Expires January 14, 2014 [Page 4]
Internet-Draft CoAP/A July 2013
3. Base64 encoding for CoAP
3.1. Overview
A CoAP node MAY consist of the CPU module and the communication
module logically or physically. Some communication modules do not
support binary encoded messages. To use the communication modules
which do not support binary messages, the CPU module in CoAP node
SHOULD encode a binary coded CoAP message to an ASCII based text
message before passing the message to the communication module. After
the communication module passes the message to the CPU module, the
CPU module SHOULD decode the ASCII based text message to the binary
CoAP message. A CoAP node can use a normal CoAP protocol software
stack with this translation.
In this document, we use Base64 encoding[BASE64]. Base64 is a binary-
to-text encoding scheme that represent binary data in an ASCII string
by a radix-64 representation. There are some variations in Base64
characters. For example, MIME's Base64 uses A-Z, a-z, 0-9, '+', and
'/'. And, '=' is used as a padding character. The number of encoded
bytes per original bytes is approximately 4/3 (33% overhead). In this
document, we use Base64url encoding that '-'(minus) character is used
instead of '+'(plus) and '_'(underline) character is used instead of
'/' (slash). This is a URL and file name safe version of Base64
variations. And, some communication module may translate '+' as an
escape character. Therefore, the '+'(plus) character SHOULD NOT be
used for the communication.
In this document, '#' is used as the end of message. Therefore, the
CPU module in CoAP node SHOULD add '#' character at the end of Base64
encoded message. It helps the message fragmentation and reassembly.
The sender side MAY send the partial encoded messages. The receiver
side SHOULD reassemble the messages until '#' is received. The sender
MAY send some white space characters, i.e., carriage return, line
feed, space, or tab, between fragmented messages. The receiver SHOULD
ignore all characters besides Base64url character set and '='
character.
The following figure shows how ASCII encoding method for Constrained
Application Protocol works. The Base64 encoding/decoding software
module runs independently from CoAP protocol stack.
Seokkap, et al. Expires January 14, 2014 [Page 5]
Internet-Draft CoAP/A July 2013
<Sending Node> <Receiving Node>
+--------+ +--------+ (communication) +--------+ +--------+
|CoAP | |Base64 | (channel) |Base64 | |CoAP |
|protocol|--+Encoding|---------------->|Decoding|--|protocol|
|stack | |+"#" | |-"#' | |stack |
+--------+ +--------+ +--------+ +--------+
3.2. Examples
In the appendix A in CoAP draft-18, a confirmable request and piggy-
backed response message example is described.
Client Server
| |
| |
+----->| Header: GET (T=CON, Code=0.01, MID=0x7d34)
| GET | Uri-Path: "temperature"
| |
| |
|<-----+ Header: 2.05 Content (T=ACK,Code=2.05,MID=0x7d34)
| 2.05 | Payload: "22.3 C"
| |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 0 | GET=1 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 11 | 11 | "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 | 0 | 2.05=69 | MID=0x7d34 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Seokkap, et al. Expires January 14, 2014 [Page 6]
Internet-Draft CoAP/A July 2013
Original binary encoded CoAP Request:
40 01 7d 34 bb 74 65 6d 70 65 72 61 74 75 72 65
Original binary encoded CoAP Response:
60 45 7d 34 ff 32 32 2e 33 43
These messages are converted to the Base64 encoded messages as the
follows.
Text encoded CoAP Request:
QAF9NLt0ZW1wZXJhdHVyZQ==#
This message is written in hex string as the follows.
51 41 46 39 4e 4c 74 30 5a 57 31 77 5a 58 4a 68 64
48 56 79 5a 51 3d 3d 23
Text encoded CoAP Response:
YEV9NP8yMi4zIEM=#
This message is written in hex string as the follows.
59 45 56 39 4e 50 38 79 4d 69 34 7a 49 45 4d 3d 23
4. Security Considerations
TODO - fill in
5. IANA Considerations
TODO - fill in
Seokkap, et al. Expires January 14, 2014 [Page 7]
Internet-Draft CoAP/A July 2013
6. Acknowledgments
TODO - fill in
7. References
7.1. Normative References
[COAP] Z. Shelby, K. Hartke, C. Bormann, "Constrained Application
Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013.
[BASE64] S. Josefsson, "The Base16, Base32, and Base64 Data
Encodings", IETF RFC-4648, October 2006.
Seokkap, et al. Expires January 14, 2014 [Page 8]
Internet-Draft CoAP/A July 2013
Author's Addresses
Seok-Kap Ko
ETRI
176-11 Cheomdan Gwagi-ro, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6677
Email: softgear@etri.re.kr
Ilkyun Park
ETRI
176-11 Cheomdan Gwagi-ro, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6651
Email: ikpark@etri.re.kr
Seung-Hun Oh
ETRI
176-11 Cheomdan Gwagi-ro, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6655
Email: osh93@etri.re.kr
Byung-Tak Lee
ETRI
176-11 Cheomdan Gwagi-ro, Buk-gu, Gwangju, 500-480,
Korea
Phone: +82-62-970-6624
Email: bytelee@etri.re.kr
Seokkap, et al. Expires January 14, 2014 [Page 9]
