Re: [core] HREF compression encoding

[Carsten Bormann <[e-mail]>]

Hi Jim,

This is an interesting proposal.
Klaus and I had a chat about it now, which led to the following straw man grammar:

CRI-Reference = [
  (?scheme, ?(host, ?port) // path.type),
  *path,
  ? (QUERY, +query)
  ? (FRAGMENT, fragment)
]

scheme    = ((SCHEMETEXT, text .regexp "[a-z][a-z0-9+.-]*") 
            // COAP // COAPS // HTTP // HTTPS)
host      = ((HOSTTEXT, text) // bytes .size 4 // bytes .size 16)
port      = 0..65535
path.type = 0..127
path      = text
query     = text
fragment  = text

SCHEMETEXT = -1
COAP = -2 COAPS = -3 HTTP = -4 HTTPS = -5
HOSTTEXT = true
QUERY = -6
FRAGMENT = -7

Obviously, the specific marker values we use could be shuffled a bit, but it seems we can cover the entire spectrum that is covered by the existing syntax.
There are a few things that need to be decided base on perceived frequency of use (e.g., are text-valued host names the likely or the unlikely case — depending on that, the marker is placed on the host text or on the path sequence, or the absent host could be represented by `false`), so we should come up with some rough estimations here.

Comments welcome...

Grüße, Carsten


> On 2020-04-22, at 20:20, Jim Schaad <[e-mail]> wrote:
> 
> 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
>  
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core