Internet DRAFT - draft-ruoska-encoding

draft-ruoska-encoding






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]