Network Working Group JP. Makela Internet-Draft March 21, 2013 Intended status: Experimental Expires: September 22, 2013 Ruoska Encoding draft-ruoska-encoding-04 Abstract This document describes hierarchically structured binary encoding format called the Ruoska Encoding (RSK). The main design goals are minimal resource usage, well defined structured with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like encoding formats of ASN.1 the main benefit is simplicity. ASN.1 with different encondings is complex and even simple implementation needs a lot of effort. 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 September 22, 2013. 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 Makela Expires September 22, 2013 [Page 1] Internet-Draft Ruoska Encoding March 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Document Structure . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Endianness . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. String Encoding . . . . . . . . . . . . . . . . . . . . . 5 3. Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Leading Byte . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Meta Frames . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Begin Frame . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. End Frame . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. Modifier Frame . . . . . . . . . . . . . . . . . . . . 8 3.2.4. Array Frame . . . . . . . . . . . . . . . . . . . . . 9 3.3. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Boolean Frame . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Integer Frames . . . . . . . . . . . . . . . . . . . . 10 3.3.3. Float Frames . . . . . . . . . . . . . . . . . . . . . 11 3.3.4. String Frame . . . . . . . . . . . . . . . . . . . . . 12 3.3.5. Binary Frame . . . . . . . . . . . . . . . . . . . . . 12 3.3.6. DateTime Frame . . . . . . . . . . . . . . . . . . . . 13 3.3.7. Timestamp Frame . . . . . . . . . . . . . . . . . . . 14 3.4. Extended Frames . . . . . . . . . . . . . . . . . . . . . 15 4. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Identifier Types in Leading Byte . . . . . . . . . . . . . 17 4.2. Null Identifier . . . . . . . . . . . . . . . . . . . . . 17 4.3. Integer Identifiers . . . . . . . . . . . . . . . . . . . 18 4.4. String Identifier . . . . . . . . . . . . . . . . . . . . 18 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 19 5.1. Minimal Requirements . . . . . . . . . . . . . . . . . . . 19 5.2. Forward Compatibility . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Makela Expires September 22, 2013 [Page 2] Internet-Draft Ruoska Encoding March 2013 1. Introduction The RSK is very suitable for fast prototyping and studying data exchange and storage solutions in environments with wide range of different kind of devices from small microcontrollers to mainframe computers. Only small subset of all features and data types are strictly required for every single implementation. This enables implementations for minimal systems like microcontrollers with modest computing capacity and memory. Minimal requirements are defined in Section 5.1. This version defines also mechanisms for later extensions. Actual structures and data types are not known but common structure for extended features is defined so they can be skipped by implementation versions which are not able interpret them. See Section 5.2 for details. Makela Expires September 22, 2013 [Page 3] Internet-Draft Ruoska Encoding March 2013 2. Document Structure The principal entity of RSK document is frame. Two main classes of frames exist. Meta Frames to define structure and Data Frames to hold actual payload data. Additional frame class is Extended Frame which enables forward compatibility with future versions. See Section 5.2 for details. All frames start with Leading Byte which defines frame type and some type depended instructions. Some meta frames and all data frames can be tagged with an identifier. Identifier type is defined in Leading Byte. If identifier exists it is placed right after the Leading Byte. In Data Frames payload comes after identifier. Meta Frames may also have payload or special fields or both. Data type of the payload is defined by frame type and type depended instructions. All frame types are explained in Section 3. All implementations may not be able to handle all frame types but minimal requirements are defined in Section 5.1. RSK document is structured as finite tree. The tree is rooted to Begin Frame. After the rooting Begin Frame follows data frames as leafs and Begin - End Frame pairs as branches. Branches may contain data frames as leafs and again Begin - End Frame pairs as sub branches. Nesting levels start from 0 and maximum level is artifially limited to 255 to keep implementations simple. RSK document always ends with End Frame. Use of End Frame is two fold. It is used to return from branch to parent level and terminate the document. So document must always start with Begin Frame and end with End Frame. Root nesting level 0 must not contain any other than rooting Begin and terminating End Frames. Between root Begin and terminating End Frame is nesting level 1. Nesting level 1 may contain data frames or branches or both. Example Tree Structure 0 1 2 Nesting levels | | | Begin[id:tractor] Begin Frame at level 0 | String[id:manufacturer, value:Valmet] Leaf at level 1 | String[id:model, value:33D] Leaf at level 1 | Begin[id:engine] Branch at level 1 | | String[id:fuel, value:Diesel] Leaf at level 2 | | Int8[signed:true, id:horsepower, value:37] Leaf at level 2 | End Ending branch End Terminating at level 0 Makela Expires September 22, 2013 [Page 4] Internet-Draft Ruoska Encoding March 2013 Figure 1: Tree Structure 2.1. Endianness Big-endian networking byte order is used. Endianness applies to all integer and floating point numbers. This includes payload of any data frames like Integer, Float, and Timestamp and 16-bits wide integer identifier values and also meta data fields like length of payload. Canonical network byte order is fully described in RFC791, Appendix B. 2.2. String Encoding All strings are UTF-8 encoded. This applies to string identifiers and payload of String and DateTime Frames. Implementations using String Frame, String Identifier, or DateTime Frame must be able to validate UTF-8 encoding. See RFC 3629 [RFC3629] for details. Makela Expires September 22, 2013 [Page 5] Internet-Draft Ruoska Encoding March 2013 3. Frame As mentioned earlier the principal entity is frame. This section explains all frame types and type dependent special instructions in detail. 3.1. Leading Byte All frames start with Leading Byte. Leading Byte determines frame type and type dependent instructions. The most significant bit is reserved for Extended Frames which may be introduced in later versions. See Section 3.4 and Section 5.2 for details. Leading Byte is presented as bit array where left-most bit is the most significant bit. MSB 0 bit numbering scheme is used with two exceptions. Left-most bit is reserved for Extended Frame and thus marked as 'X' for all Leading Byte definitions. Also some bits are marked with 'R' meaning that they are reserved for later use and must not be set in this version. Leading Byte is followed by frame type dependent fields like Identifier or Payload or both. These fields are presented as labeled byte blocks with possible lengths in bytes or in kilobytes like 64k. Leading Byte Example Field Example Payload +-+-------+-----+ +-------------+ +---------------+ |X|1|2|3|4|5|6|7| | 4 or 8 | | 0 - 64k | +-+-------+-----+ +-------------+ +---------------+ | \ / \ / | \ / \ / | \ / | Frame type dependent instructions bits | | | | Frame type bits | | Extended frame bit Leading Byte Example Field: Example of possible frame type dependent byte field. 4 or 8 means that field can be 4 or 8 bytes long. Actual length can be determined by frame type, instruction bits, or some other field. Example Payload: Example of possible frame type dependent payload field. 0 - 64k means that field can be from 0 to 65535 bytes long. Actual length can be determined by frame type, instruction bits, or some other field. Makela Expires September 22, 2013 [Page 6] Internet-Draft Ruoska Encoding March 2013 Frame type dependent instructions bits: These bits determine type dependent instructions. See specific frame type sections for details. Frame type bits: This bit field determines frame type. Extended frame bit: Extended frame bit. See Section 3.4 for details. 3.2. Meta Frames Meta Frames define document structure. Some of the Meta Frames are optional for minimal implementations. See Section 5.1 for details. 3.2.1. Begin Frame Document and branches starts with Begin Frame. Begin Frame may have an identifier. More details about tree structure see Section 2. Leading Byte Identifier +-+-------+-+---+ +----------+ |X|1|2|3|4|R|6|7| | 0 - 256 | +-+-------+-+---+ +----------+ \ / \ / \ / | Id bits \ / | Type bits Begin Frame Identifier & Id bits: See Section 4 for details. Type bits: Begin Frame type: 0000 3.2.2. End Frame End Frame is used to return from branch to parent level in tree structure and also used to terminate a document. More details about tree structure see Section 2. Leading Byte +-+-------+-----+ |X|1|2|3|4|R|R|R| +-+-------+-----+ \ / \ / \ / | Type bits Makela Expires September 22, 2013 [Page 7] Internet-Draft Ruoska Encoding March 2013 End Frame Type bits: End Frame type: 0001 3.2.3. Modifier Frame Modifier Frame is used to apply a modifier for example compression or encryption to same portions of document. RSK does not define any modifiers. When used they are defined in specifications based on RSK. Modified payload must consists of valid frames. On reading phase payload and meta data is passed to demodifier routine and then handled like ordinary frames. Modifier Frame is wrapper for other frames but not a sub branch for document tree structure. Payload may contain sub branches but branches must return to same nesting level as at beginning of payload. Meta field is intended to be used to store modifier specific data. For example original data length and padding byte count for a block compression. Meaning of Meta data must be defined in specifications based on RSK when Modifier Frame is used. Leading Byte Identifier MetLen Meta Length Payload +-+-------+-+---+ +---------+ +----+------+ +----+ +---------+ |X|1|2|3|4|R|6|7| | 0 - 256 | | 2 | 0-4k | | 2 | | 0 - 64k | +-+-------+-+---+ +---------+ +----+------+ +----+ +---------+ \ / \ / \ / | Id bits \ / | | Type bits Figure 2: Modifier Frame Identifier & Id bits: See Section 4 for details. MetLen: 16-bits wide unsigned integer telling length of meta data. MetLen must not exceed 4095 bytes! Meta: Custom meta data. Length: 16-bits wide unsigned integer telling length of modified payload data. Makela Expires September 22, 2013 [Page 8] Internet-Draft Ruoska Encoding March 2013 Payload: Modified payload data. Type bits: Modifier Frame type: 0010 3.2.4. Array Frame Fixed length Integer or Float frames with null or integer identifier can be enclosed into an array. This saves some resources when dealing with large number of items. This can be also used to make portions of encoded document random accessible. Array itself and each item may have identifiers. All items are same type. All items have identifier of same type. Frame and identifier type for all items are defined by CLB (Common Leading Byte). Leading Byte Identifier CLB Length II IP +-+-------+-+---+ +---------+ +---+ +-------+ +-------+-------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 | | 1 - 2 | | 0 - 2 | 1 - 8 | * * * +-+-------+-+---+ +---------+ +---+ +-------+ +-------+-------+ \ / | \ / | | \ / | | Id bits \---- Array items ----/ \ / | | | Length bit | | Type bits Array Frame Identifier & Id bits: Array identifier. See Section 4 for details. CLB: Common Leading Byte for all Items. Determines type of Item and it's identifier. Frame type must be Integer or Float and identifier type must be Null or Integer. Length: 8 or 16-bits wide unsigned integer telling length of array items in bytes. II: Item Identifier. See Section 4 for details. IP: Item Payload. Length bit: If bit is set then Length is 16-bits otherwise 8-bits wide unsigned integer. Type bits: Array Frame type: 0011 Makela Expires September 22, 2013 [Page 9] Internet-Draft Ruoska Encoding March 2013 3.3. Data Frames Data Frames are collection of widely used data types. There are frames for boolean, integer and floating point numbers, UTF-8 encoded strings, dates, and timestamps. There is also frame for raw binary data. All data frames can be tagged with an identifier. 3.3.1. Boolean Frame Boolean frame can hold single True or False value. Leading Byte Identifier +-+-------+-+---+ +----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | +-+-------+-+---+ +----------+ \ / | \ / \ / | | Id bits \ / | | | Boolean bit | | Type bits Boolean Frame Identifier & Id bits: See Section 4 for details. Boolean bit: If Boolean bit is set when boolean value is True otherwise False. Type bits: Boolean Frame type: 0100 3.3.2. Integer Frames Wide range of integer types are supported. Integer width is defined by choosing corresponding Integer Frame type. Integers can be defined as unsigned by setting Unsigned bit in Leading Byte otherwise they are signed. Negative values of signed integers are presented in two's complement notation. Integer payload is always stored in big-endian format. See Section 2.1 for details. Makela Expires September 22, 2013 [Page 10] Internet-Draft Ruoska Encoding March 2013 Leading Byte Identifier Payload +-+-------+-+---+ +----------+ +--------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1,2,4 or 8 | +-+-------+-+---+ +----------+ +--------------+ \ / | \ / \ / | | Id bits \ / | | | Unsigned bit | | Type bits Integer Frames Identifier & Id bits: See Section 4 for details. Unsigned bit: If Unsigned bit is set when payload is unsigned otherwise signed integer. Payload: Payload integer value. Type bits: Integer Frame types: 0101 8-bits wide integer. 0110 16-bits wide integer. 0111 32-bits wide integer. 1000 64-bits wide integer. 3.3.3. Float Frames Floating point number precision is defined by choosing corresponding Float Frame type. Floats are presented in IEEE754 standard format and endianness big-endian. See Section 2.1 for details. Leading Byte Identifier Payload +-+-------+-+---+ +----------+ +------------+ |X|1|2|3|4|R|6|7| | 0 - 256 | | 2,4 or 8 | +-+-------+-+---+ +----------+ +------------+ \ / \ / \ / | Id bits \ / | | | Type bits Float Frames Makela Expires September 22, 2013 [Page 11] Internet-Draft Ruoska Encoding March 2013 Identifier & Id bits: See Section 4 for details. Payload: Payload float value. Type bits: Float Frame types: 1001 16-bits wide half precision float. 1010 32-bits wide single precision float. 1011 64-bits wide double precision float. 3.3.4. String Frame String Frame can hold UTF-8 encoded string. If implementation supports String Frame it must be able to validate UTF-8 encoding. See Section 2.2 for details. Leading Byte Identifier Length Payload +-+-------+-+---+ +----------+ +-------+ +-------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 - 2 | | 0 - 64k | +-+-------+-+---+ +----------+ +-------+ +-------------+ \ / | \ / \ / | | Id bits \ / | | | Length bit | | Type bits String Frame Identifier & Id bits: See Section 4 for details. Length: 8 or 16-bits wide unsigned integer telling length of string in bytes. Length bit: If bit is set then Length is 16-bits otherwise 8-bits wide unsigned integer. Payload: UTF-8 encoded string. Type bits: String Frame type: 1100 3.3.5. Binary Frame Single Binary Frame can hold up to 65535 bytes and obviously a document may contain as many binary frames as needed. So the only issue with big binary masses is data fragmentation to multiple Makela Expires September 22, 2013 [Page 12] Internet-Draft Ruoska Encoding March 2013 frames. Leading Byte Identifier Length Payload +-+-------+-+---+ +----------+ +-------+ +-------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 - 2 | | 0 - 64k | +-+-------+-+---+ +----------+ +-------+ +-------------+ \ / | \ / \ / | | Id bits \ / | | | Length bit | | Type bits Binary Frame Identifier & Id bits: See Section 4 for details. Length: 8 or 16-bits wide unsigned integer telling length of payload in bytes. Length bit: If bit is set then Length is 16-bits otherwise 8-bits wide unsigned integer. Payload: Binary payload. Type bits: Binary Frame type: 1101 3.3.6. DateTime Frame DateTime Frame holds date or date and time in UTC timescale as UTF-8 encoded string. Date is presented as ("YYYY-MM-DD") and DateTime is ("YYYY-MM-DDTHH:MM:SS.SSSZ"). String formats are compatible with RFC 3339 [RFC3339]. If implementation supports DateTime Frame it must be able to validate UTF-8 encoding. See Section 2.2 for details. Leading Byte Identifier Date/DateTime +-+-------+-+---+ +----------+ +-----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 10 or 24 | +-+-------+-+---+ +----------+ +-----------+ \ / | \ / \ / | | Id bits \ / | | | DateTime bit | | Type bits Makela Expires September 22, 2013 [Page 13] Internet-Draft Ruoska Encoding March 2013 DateTime Frame Identifier & Id bits: See Section 4 for details. Date/DateTime: Date or DateTime string. DateTime bit: If bit is set then payload is DateTime otherwise Date. Type bits: DateTime Frame type: 1110 3.3.7. Timestamp Frame Timestamp is very similar, with some exceptions, as NTP Date Format defined in RFC 5905 [RFC5905]. Differences to NTP Date Format Width of Era field: NTP Date Format has 32-bits wide Era field. Here Era is only 8-bits wide. Intepretation is same but with narrowed range. Epoch is same so Era 0 starts at 1900-01-01 00: 00:00 UTC like in NTP Date Format. Fraction field is optional: In NTP Date Format Fraction field always exists. Here it is optional. It exists only if Fraction bit is set in Leading Byte. Width of Fraction Field: NTP Date Format uses 64-bits wide Fraction field. Here fraction is only 32-bits wide and thus capable to 232 picosecond resolution. Leading Byte Identifier Era Offset Fraction +-+-------+-+---+ +----------+ +---+ +------+ +--------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 | | 4 | | 0 or 4 | +-+-------+-+---+ +----------+ +---+ +------+ +--------+ \ / | \ / \ / | | Id bits \ / | | | Fraction bit | | Type bits Timestamp Frame Makela Expires September 22, 2013 [Page 14] Internet-Draft Ruoska Encoding March 2013 Identifier & Id bits: See Section 4 for details. Era: 8-bit signed integer telling the era of timestamp. See RFC 5905 [RFC5905] for era definitions. Offset: 32-bit unsigned integer holding number of seconds since beginning of the Era. Fraction: 32-bit unsigned integer holding fractions of second. Fraction bit: If Fraction bit is set then optional Fraction field exists. Type bits: Timestamp Frame type: 1111 3.4. Extended Frames Extended Frame is concept to introduce new structures and data types to future versions of RSK. The most significant bit in Leading Byte is reserved for Extended Frames. In this version Extended bit must not be set when writing a RSK document. Forward compatible implementations must be able to detect Extended Frames and interprete Length bit and Length field to get correct length of payload. Payload can be then skipped and processing continues with next frame. Extended Frame is not part of Minimal Requirements see Section 5.1. Leading Byte Length Payload +-+-----------+-+ +--------+ +---------+ |X|1|2|3|4|5|6|7| | 1 - 2 | | 0 - 64k | +-+-----------+-+ +--------+ +---------+ | \ / | | \---+---/ | Length bit | | | | Type and instructions bits | | Extended bit Extended Frames Length: 8 or 16-bits wide unsigned integer telling length of payload in bytes. Makela Expires September 22, 2013 [Page 15] Internet-Draft Ruoska Encoding March 2013 Payload: Payload can be skipped in this version. Length bit: If bit is set then Length is 16-bits otherwise 8-bits wide unsigned integer. Type and instructions bits: Extended Frame type and instruction bits will be defined in future Ruoska Encoding versions. These can be skipped in this version. Extended bit: If set frame must be handled as Extended Frame. Makela Expires September 22, 2013 [Page 16] Internet-Draft Ruoska Encoding March 2013 4. Identifiers All data frames and some of the meta frames can be tagged with an identifier. Identifier can be defined as 8 or 16-bit wide unsigned integer or as length-prefixed UTF-8 encoded string. If identifier is not needed it can be set to Null. Frame's Leading Byte tells type of identifier. Identifier bytes are placed immediately after the Leading Byte. In case of integer identifier there is one or two bytes depending on selected integer width. String identifier can take up to 256 bytes. See following sections for details. All identifier types are not required for minimal implementations. See Section 5.1 for details. 4.1. Identifier Types in Leading Byte Two least significant bits of Leading Byte are reserved for Id bits in all frame types which can be tagged with an identifier. Leading Byte Identifier +-+---------+---+ +----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | +-+---------+---+ +----------+ \ / | Id bits Identifier Types Id bits values and identifier types: 00 Null Identifier. See Section 4.2. 01 8-bits wide Integer Identifier. See Section 4.3. 10 16-bits wide Integer Identifier. See Section 4.3. 11 String Identifier. See Section 4.4 4.2. Null Identifier Some frames in a document may not need identifier so it can be left empty by setting it Null in Leading Byte. Makela Expires September 22, 2013 [Page 17] Internet-Draft Ruoska Encoding March 2013 4.3. Integer Identifiers Integer identifier types are 8 or 16-bits wide unsigned integers. Integer identifiers are presented in big-endian format as all numbers in RSK. See Section 2.1 for details. 4.4. String Identifier String identifier is length-prefixed and UTF-8 encoded. Length is presented by one byte as 8-bits wide unsigned integer at the beginning of identifier field. String identifier itself can be 255 bytes long at maximum. If implementation supports string identifiers it must be able to validate UTF-8 encoding. See Section 2.2 for details. Leading Byte Length UTF-8 Encoded String +---------------+ +--------+ +----------------------+ |X|1|2|3|4|5|6|7| | 1 byte | | 0 - 255 bytes | +---------------+ +--------+ +----------------------+ | | \---------- Identifier -----------/ String Identifier Makela Expires September 22, 2013 [Page 18] Internet-Draft Ruoska Encoding March 2013 5. Implementation Notes RSK is designed so that implementations could have very small memory and other resource demands. Pay attention to memory usage and try to perform IO operations efficiently. Implementations must make sure that well formed documents are written. On reading phase any deformation in document or frame structure must be detected and handled as error condition. Implementations can vary many ways depending on environment and usage. Minimal Requirements define absolute minimum requirements for all implementations. All other feature can be left out to save resources in implementations for small devices. See Section 5.1 for details. 5.1. Minimal Requirements Absolute minimal requirements for all implementations to be compatible with RSK are listed here. Binary Frame Payload length: 8 bytes. Nesting levels: 0 - 255 Meta Frame types: Begin and End Frames. Identifier types: Null and Integer identifiers. Data Frame types: Boolean, Binary, and 8 and 16-bits wide Integer Frames. All other features like frame types Array, Modifier, Float, String, DateTime, and Timestamp are optional. String identifier is optional. Longer than 8 bytes payloads are optional. Support for Extended Frames is also optional. 5.2. Forward Compatibility An implementation may take advantage of Extended Frame concept to provide forward compatibility for later RSK versions. This is not required for all implementations and can be left out if not needed. See Section 5.1 for Minimal Requirements and Section 3.4 for Extended Frame. Makela Expires September 22, 2013 [Page 19] Internet-Draft Ruoska Encoding March 2013 6. Security Considerations RSK is data encoding format and does not include any executable commands. Implementations must make sure that any parts of encoded documents are not leaked into execution memory. Even malformed documents must be handled so that memory leaks are avoided. RSK does not include any means to validate payload data integrity. Protocols based on RSK or underlying mechanisms which are utilized by those protocols must take care of this. If data integrity is not checked can data get corrupted by malfunctioning devices, software, or malicious attackers. Modifier Frame enables encryption for selected portions of a document. RSK does not define any encryption methods but almost any kind of encryption cipher could be used. If needed encryption methods should be defined in specifications based on RSK. Makela Expires September 22, 2013 [Page 20] Internet-Draft Ruoska Encoding March 2013 7. IANA Considerations The MIME media type for RSK documents is application/ruoska. Type name: application Subtype name: ruoska Required parameters: n/a Optional parameters: n/a Makela Expires September 22, 2013 [Page 21] Internet-Draft Ruoska Encoding March 2013 8. Normative References [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. Makela Expires September 22, 2013 [Page 22] Internet-Draft Ruoska Encoding March 2013 Author's Address Jukka-Pekka Makela Janakkala, Finland Makela Expires September 22, 2013 [Page 23]