Network Working Group JP. Makela Internet-Draft October 12, 2013 Intended status: Experimental Expires: April 15, 2014 Ruoska Encoding draft-ruoska-encoding-06 Abstract This document describes hierarchically structured binary encoding format called Ruoska Encoding (later RSK). The main design goals are minimal resource usage, well defined structure 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 BER encoding of ASN.1 the main benefit is simplicity. ASN.1 with many different encodings is complex and even simple implementation needs a lot of effort. RSK is also more efficient than BER. 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 April 15, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Makela Expires April 15, 2014 [Page 1] Internet-Draft Ruoska Encoding October 2013 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. Table of Contents 1. Document Structure . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Endianness . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. String Encoding . . . . . . . . . . . . . . . . . . . . . 4 2. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Leading Byte . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Meta Frames . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Null Frame . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Begin Frame . . . . . . . . . . . . . . . . . . . . . 6 2.2.3. End Frame . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Array Frame . . . . . . . . . . . . . . . . . . . . . 7 2.3. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1. Boolean Frame . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Integer Frames . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Float Frames . . . . . . . . . . . . . . . . . . . . . 10 2.3.4. String Frame . . . . . . . . . . . . . . . . . . . . . 10 2.3.5. Binary Frame . . . . . . . . . . . . . . . . . . . . . 11 2.3.6. DateTime Frames . . . . . . . . . . . . . . . . . . . 12 2.3.7. NTP Short Frame . . . . . . . . . . . . . . . . . . . 13 2.3.8. NTP Timestamp Frame . . . . . . . . . . . . . . . . . 13 2.3.9. NTP Date Frame . . . . . . . . . . . . . . . . . . . . 14 2.3.10. RSK Date Frame . . . . . . . . . . . . . . . . . . . . 14 2.4. Extended Frames . . . . . . . . . . . . . . . . . . . . . 15 3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Identifier Types in Leading Byte . . . . . . . . . . . . . 16 3.2. Null Identifier . . . . . . . . . . . . . . . . . . . . . 16 3.3. Integer Identifiers . . . . . . . . . . . . . . . . . . . 16 3.4. String Identifier . . . . . . . . . . . . . . . . . . . . 17 4. Frame Type Table . . . . . . . . . . . . . . . . . . . . . . . 18 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Normative References . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Makela Expires April 15, 2014 [Page 2] Internet-Draft Ruoska Encoding October 2013 1. 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. 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 2. 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. Null and Array Frames are considered as data frames here. 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 | | UInt8[id:horsepower, value:37] Leaf at level 2 | End Ending branch End Terminating at level 0 Figure 1: Tree Structure Makela Expires April 15, 2014 [Page 3] Internet-Draft Ruoska Encoding October 2013 1.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. 1.2. String Encoding All strings are UTF-8 encoded. This applies to string identifiers and payload of String, Date, DateTime and DateTimeMillis Frames. Implementations using any of frame types above or String Identifier or both must be able to validate UTF-8 encoding. On writing phase UTF-8 encoding violation must be handled as error condition. If UTF-8 encoding fails on reading phase warning must be raised and let user decide to continue reading or not. More information about UTF-8 see RFC 3629 [RFC3629]. Makela Expires April 15, 2014 [Page 4] Internet-Draft Ruoska Encoding October 2013 2. Frame Definitions As mentioned earlier the principal entity of RSK is frame. This section explains all frame types and type dependent special instructions in detail. 2.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 2.4 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, kilobytes like 64k, or gigabytes like 4G. 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 Figure 2: 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 April 15, 2014 [Page 5] Internet-Draft Ruoska Encoding October 2013 Frame type dependent instructions bits: These bits determine type dependent instructions. See specific frame type sections for details. For most frame types these are used to define identifier type. Frame type bits: This bit field determines frame type. Values are defined in Section 4. Extended frame bit: Extended frame bit. See Section 2.4 for details. 2.2. Meta Frames Meta Frames define document structure. 2.2.1. Null Frame Null Frame can be tagged with an identifier but does not contain any payload data. Leading Byte Identifier +-+---------+---+ +---------+ |X|1|2|3|4|5|6|7| | 0 - 256 | +-+---------+---+ +---------+ \ / \ / \ / | Id bits | | Type bits Figure 3: Null Frame Identifier & Id bits: See Section 3 for details. Type bits: See Section 4. 2.2.2. Begin Frame Document and branches start with Begin Frame. Begin Frame may have an identifier. More details about tree structure see Section 1. Makela Expires April 15, 2014 [Page 6] Internet-Draft Ruoska Encoding October 2013 Leading Byte Identifier +-+---------+---+ +----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | +-+---------+---+ +----------+ \ / \ / \ / | Id bits | | Type bits Figure 4: Begin Frame Identifier & Id bits: See Section 3 for details. Type bits: See Section 4. 2.2.3. 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 1. Leading Byte +-+---------+---+ |X|1|2|3|4|5|R|R| +-+---------+---+ \ / \ / | | Type bits Figure 5: End Frame Type bits: See Section 4. 2.2.4. Array Frame Array column in Frame Type Table in Section 4 defines frame types which can be enclosed into a array. Array itself and each item may have identifiers. Array identifier is defined in Leading Byte. All items have identifier of same type and all items are same frame type. Frame and identifier type for all items are defined by CLB (Common Leading Byte). Array capacity is defined by selecting corresponding Array Frame Makela Expires April 15, 2014 [Page 7] Internet-Draft Ruoska Encoding October 2013 type. See Section 4 for details. Leading Byte Identifier CLB Count Items +-+---------+---+ +---------+ +---+ +-------+ +-------+ +-------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 | | 1/2/4 | | Item1 | | Item2 | ... +-+---------+---+ +---------+ +---+ +-------+ +-------+ +-------+ \ / \ / \ / | Id bits | | Type bits Figure 6: Array Frame Identifier & Id bits: Array identifier. See Section 3 for details. CLB: Common Leading Byte determines type of items and type of item identifiers. Count: 8, 16, or 32-bits wide unsigned integer telling item count. Width of Count field depends on array type, see Section 4 for details. Items: Array of items. Type bits: See Section 4. Array items are stored right after Count field. Items may have Identifier. Identifier Item Payload +------------+ +--------------+ | 0 - 256 | | 1 - 4G | +------------+ +--------------+ Figure 7: Array Item 2.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. Makela Expires April 15, 2014 [Page 8] Internet-Draft Ruoska Encoding October 2013 2.3.1. Boolean Frame Boolean value (False/True) is defined by choosing corresponding Boolean Frame type. See Section 4. Leading Byte Identifier +-+---------+---+ +----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | +-+---------+---+ +----------+ \ / \ / \ / | Id bits | | Type bits Figure 8: Boolean Frame Identifier & Id bits: See Section 3 for details. Type bits: See Section 4. 2.3.2. Integer Frames Wide range of integer types are supported. Integer width and signedness are defined by choosing corresponding Integer Frame type. Signed integers are presented in two's complement notation. Integer payload is always stored in big-endian format. See Section 1.1 for details. Leading Byte Identifier Payload +-+---------+---+ +----------+ +--------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1,2,4 or 8 | +-+---------+---+ +----------+ +--------------+ \ / \ / \ / | Id bits | | Type bits Figure 9: Integer Frames Makela Expires April 15, 2014 [Page 9] Internet-Draft Ruoska Encoding October 2013 Identifier & Id bits: See Section 3 for details. Payload: Payload integer value. Type bits: See Section 4. 2.3.3. Float Frames Floating point number precision is defined by choosing corresponding Float Frame type. See Section 4 for frame types. Floats are presented in IEEE754 standard format and endianness is big-endian. See Section 1.1 for details. Leading Byte Identifier Payload +-+---------+---+ +----------+ +------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 2,4 or 8 | +-+---------+---+ +----------+ +------------+ \ / \ / \ / | Id bits | | Type bits Figure 10: Float Frames Identifier & Id bits: See Section 3 for details. Payload: Payload float value. Type bits: See Section 4. 2.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 1.2 for details. Frame capacity is defined by selecting corresponding String Frame type. See Section 4 for details. Makela Expires April 15, 2014 [Page 10] Internet-Draft Ruoska Encoding October 2013 Leading Byte Identifier Length Payload +-+---------+---+ +----------+ +-------+ +-----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1/2/4 | | 0 - 4G | +-+---------+---+ +----------+ +-------+ +-----------+ \ / \ / \ / | Id bits | | Type bits Figure 11: String Frame Identifier & Id bits: See Section 3 for details. Length: 8, 16, or 32-bits wide unsigned integer telling length of string in bytes. Depends on String Frame type, see Section 4 for details. Payload: UTF-8 encoded string. Type bits: See Section 4. 2.3.5. Binary Frame Binary Frame holds arbitrary binary data. Frame capacity is defined by selecting corresponding Binary Frame type. See Section 4 for details. Leading Byte Identifier Length Payload +-+---------+---+ +----------+ +-------+ +-----------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1/2/4 | | 0 - 4G | +-+---------+---+ +----------+ +-------+ +-----------+ \ / \ / \ / | Id bits | | Type bits Figure 12: Binary Frame Identifier & Id bits: See Section 3 for details. Length: 8, 16, or 32-bits wide unsigned integer telling length of payload in bytes. Depends on Binary Frame type, see Section 4 for details. Makela Expires April 15, 2014 [Page 11] Internet-Draft Ruoska Encoding October 2013 Payload: Arbitrary binary data. Type bits: See Section 4. 2.3.6. DateTime Frames DateTime Frames hold date or date and time in UTC timescale as UTF-8 encoded string. String formats are compatible with RFC 3339 [RFC3339]. If implementation supports any of DateTime Frames it must be able to validate UTF-8 encoding. See Section 1.2 for details. Besides string formats must be validated but date data validation is not part of RSK. On writing phase illegal string format must be handled as error. On reading phase string format violation can be handled by rising warning and let user decide continue reading or not. Date frame types and corresponding date string formats: Date: YYYY-MM-DD DateTime: YYYY-MM-DDTHH:MM:SSZ DateTimeMillis: YYYY-MM-DDTHH:MM:SS.SSSZ Leading Byte Identifier Date/DateTime/DateTimeMillis +-+-------+-+---+ +----------+ +----------------------------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 10/20/24 | +-+-------+-+---+ +----------+ +----------------------------+ \ / \ / \ / | Id bits | | Type bits Figure 13: DateTime Frame Identifier & Id bits: See Section 3 for details. Date/DateTime/DateTimeMillis: Date, DateTime, or DateTimeMillis string depends of date frame type. Type bits: See Section 4. Makela Expires April 15, 2014 [Page 12] Internet-Draft Ruoska Encoding October 2013 2.3.7. NTP Short Frame NTP Short Frame holds NTP Short Format compatible timestamp. See RFC 5905 [RFC5905] for details. Leading Byte Identifier Seconds Fraction +-+-------+-+---+ +----------+ +-------+ +--------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 2 | | 2 | +-+-------+-+---+ +----------+ +-------+ +--------+ \ / \ / \ / | Id bits | | Type bits Figure 14: NTP Short Format Frame Identifier & Id bits: See Section 3 for details. Seconds: 16-bits unsigned integer telling seconds. Fraction: 16-bits unsigned integer holding fractions of second. Type bits: See Section 4. 2.3.8. NTP Timestamp Frame NTP Timestamp Frame holds NTP Timestamp Format compatible timestamp. See RFC 5905 [RFC5905] for details. Leading Byte Identifier Seconds Fraction +-+-------+-+---+ +----------+ +-------+ +--------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 4 | | 4 | +-+-------+-+---+ +----------+ +-------+ +--------+ \ / \ / \ / | Id bits | | Type bits Figure 15: NTP Timestamp Format Frame Makela Expires April 15, 2014 [Page 13] Internet-Draft Ruoska Encoding October 2013 Identifier & Id bits: See Section 3 for details. Seconds: 32-bits unsigned integer telling seconds. Fraction: 32-bits unsigned integer holding fractions of second. Type bits: See Section 4. 2.3.9. NTP Date Frame NTP Date Frame holds NTP Date Format compatible date. See RFC 5905 [RFC5905] for details. Leading Byte Identifier Era Era Offset Fraction +-+-------+-+---+ +----------+ +---+ +----------+ +--------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 4 | | 4 | | 8 | +-+-------+-+---+ +----------+ +---+ +----------+ +--------+ \ / \ / \ / | Id bits | | Type bits Figure 16: NTP Date Format Frame Identifier & Id bits: See Section 3 for details. Era: 32-bits signed integer telling the era of timestamp. See RFC 5905 [RFC5905] for era definitions. Offset: 32-bits unsigned integer holding number of seconds since beginning of the Era. Fraction: 64-bits unsigned integer holding fractions of second. Type bits: See Section 4. 2.3.10. RSK Date Frame RSK Date is optimized version of NTP Date Format defined in RFC 5905 [RFC5905]. Differences with NTP Date Format Makela Expires April 15, 2014 [Page 14] Internet-Draft Ruoska Encoding October 2013 Width of Era field: NTP Date Format has 32-bits wide Era field. Here Era is only 8-bits wide. Interpretation 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. Width of Fraction Field: NTP Date Format uses 64-bits wide Fraction field. Here fraction is only 16-bits wide and thus capable to 16 microsecond resolution. Leading Byte Identifier Era Era Offset Fraction +-+-------+-+---+ +----------+ +---+ +----------+ +--------+ |X|1|2|3|4|5|6|7| | 0 - 256 | | 1 | | 4 | | 2 | +-+-------+-+---+ +----------+ +---+ +----------+ +--------+ \ / \ / \ / | Id bits | | Type bits Figure 17: RSK Date Frame Identifier & Id bits: See Section 3 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: 16-bit unsigned integer holding fractions of second. Type bits: See Section 4. 2.4. Extended Frames Extended Frame is concept to introduce new structures and data types in 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. If Extended Frame is discovered on reading phase it must be handles as error in this version. Makela Expires April 15, 2014 [Page 15] Internet-Draft Ruoska Encoding October 2013 3. 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 identifier type. String identifier can take up to 256 bytes. See following sections for details. 3.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 Figure 18: Identifier Types Id bits values and identifier types: 00 Null Identifier. See Section 3.2. 01 8-bits wide Integer Identifier. See Section 3.3. 10 16-bits wide Integer Identifier. See Section 3.3. 11 String Identifier. See Section 3.4 3.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. 3.3. Integer Identifiers Integer identifier types are 8 or 16-bits wide unsigned integers. Integer identifiers are presented in big-endian format. See Makela Expires April 15, 2014 [Page 16] Internet-Draft Ruoska Encoding October 2013 Section 1.1 for details. Leading Byte Uint8 Uint16 +---------------+ +-------+ +----------+ |X|1|2|3|4|5|6|7| | 1 | OR | 2 | +---------------+ +-------+ +----------+ | | \---Integer Identifier ---/ Figure 19: Integer Identifier 3.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 0 - 255 bytes long. If implementation supports string identifiers it must be able to validate UTF-8 encoding. See Section 1.2 for details. Leading Byte Length UTF-8 Encoded String +---------------+ +--------+ +----------------------+ |X|1|2|3|4|5|6|7| | 1 | | 0 - 255 | +---------------+ +--------+ +----------------------+ | | \------ String Identifier --------/ Figure 20: String Identifier Makela Expires April 15, 2014 [Page 17] Internet-Draft Ruoska Encoding October 2013 4. Frame Type Table No Frame Type Id Array Payload ------------------------------------------------------------------- 1. Null 0x00 [x] [ ] 0 2. Begin 0x04 [x] [ ] 0 3. End 0x08 [ ] [ ] 0 4. Boolean False 0x0C [x] [ ] 0 5. Boolean True 0x10 [x] [ ] 0 6. TinyArray 0x14 [x] [ ] 0 - 255 (items) 7. Array 0x18 [x] [ ] 0 - 64k (items) 8. LongArray 0x1C [x] [ ] 0 - 4G (items) 9. TinyString 0x20 [x] [x] 0 - 255 10. String 0x24 [x] [x] 0 - 64k 11. LongString 0x28 [x] [x] 0 - 4G 12. TinyBinary 0x2C [x] [x] 0 - 255 13. Binary 0x30 [x] [x] 0 - 64k 14. LongBinary 0x34 [x] [x] 0 - 4G 15. Signed int 8-bits 0x38 [x] [x] 1 16. Signed int 16-bits 0x3C [x] [x] 2 17. Signed int 32-bits 0x40 [x] [x] 4 18. Signed int 64-bits 0x44 [x] [x] 8 19. Unsigned int 8-bits 0x48 [x] [x] 1 20. Unsigned int 16-bits 0x4C [x] [x] 2 21. Unsigned int 32-bits 0x50 [x] [x] 4 22. Unsigned int 64-bits 0x54 [x] [x] 8 23. Floating 16-bits 0x58 [x] [x] 2 24. Floating 32-bits 0x5C [x] [x] 4 25. Floating 64-bits 0x60 [x] [x] 8 26. Date 0x64 [x] [x] 10 27. DateTime 0x68 [x] [x] 20 28. DateTimeMillis 0x6C [x] [x] 24 29. NTP Short Format 0x70 [x] [x] 4 30. NTP Timestamp Format 0x74 [x] [x] 8 31. NTP Date Format 0x78 [x] [x] 16 32. RSK Date 0x7C [x] [x] 7 Makela Expires April 15, 2014 [Page 18] Internet-Draft Ruoska Encoding October 2013 Frame Type Table columns: Frame: Name of frame type. See Section 2 for detailed frame definitions. Type: Hexadecimal value of Leading Byte with mask 0xFC. See Section 2.1 for detailed description of Leading Byte. Id: All marked with X has identifier field. See Section 3 for details. Array: All marked with X can be enclosed into a array. See Section 2.2.4 for details. Payload: Payload length in bytes for data frames and item count for arrays. Makela Expires April 15, 2014 [Page 19] Internet-Draft Ruoska Encoding October 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 depending on environment and usage. All implementations must support at least Begin and End Frames to be able to handle document structure. Other frame types may not be supported. Implementation may also support most or all frame types but not all identifier types. Some frame types can be also partially supported so that they can be detected and skipped on reading phase although their payload data is not interpreted. Makela Expires April 15, 2014 [Page 20] Internet-Draft Ruoska Encoding October 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. Makela Expires April 15, 2014 [Page 21] Internet-Draft Ruoska Encoding October 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 April 15, 2014 [Page 22] Internet-Draft Ruoska Encoding October 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 April 15, 2014 [Page 23] Internet-Draft Ruoska Encoding October 2013 Author's Address Jukka-Pekka Makela Janakkala, Tavastia Proper Finland Makela Expires April 15, 2014 [Page 24]