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 +--------+ +--------+ (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]