[core] HREF compression encoding

[Jim Schaad <[e-mail]>]

I had a slightly different proposal to what Klaus presented at the last
interim in terms of doing href compression.  It is based on the fact that
URIs have a relatively fixed pattern and keeps the CBOR coding directly
rather than moving to some type of binary encoding.

 

The standard pattern for a URI is scheme://hostname/path/path/.  Using this
for compression purposes by removing all of the tagging which keeps to the
same pattern you would compress coap://example.com/foo/abc.xyz to

 

[ "coap", "example.com", "foo", "abc.xyz"]

1    1          1          1          2     = 6 bytes of padding

 

This is the same amount of padding as his binary compression method.  There
is a slight loss over his method when you want to do port numbers, queries
or fragments as they would need to have a integer tag inserted so you get

 

[ "coap", "example.com", "foo", "bar", Query, "a=b", "c=d", Fragment,
"gohere"]

1    1          1           1      1     1       1     1       1        1
= 10 bytes

 

In the binary encoding this would only require 9 bytes

 

Moving to an IP address adds no additional padding as the difference between
a text string, a byte string of length either 4 or 8 can easily be detected.
Relative URIs are encoded using similar tagging so you end up with

 

[ Absolute, "foo", "bar" ]

1   1          1      1   =  4 byte

 

[ Relative, 2, "foo", "bar" ]

1   1        1   1     1        = 5 bytes

 

Using the binary mode these would be 4 bytes and  4 bytes respectively (I
think as no examples are in the slides)

 

I believe that the advantage of this proposal is that there is no new
encoder/decoder needed as this is pure CBOR.  The compressed outputs are of
similar lengths as the binary version and processing them I believe will
result in near identical code sizes.  The code to do absolute and relative
processing as well as generating CBOR options is going to be very similar.

 

Jim