SINK record does not follow spec

Summary

The SINK record defined in lib/dns/rdata/generic/sink_40.h defines a meaning field that does not corresponds to anything in the official spec (https://tools.ietf.org/html/draft-eastlake-kitchen-sink-02)

BIND version used

I'm pretty sure the behavior is the same on master but here is the version tested:

BIND 9.14.3 (Stable Release) <id:896acdc>
running on Linux x86_64 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02 UTC 2019
built by make with '--build=x86_64-alpine-linux-musl' '--host=x86_64-alpine-linux-musl' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dlopen=yes' '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' '--with-gssapi=/usr' '--with-libjson' '--with-libtool' '--with-libxml2' '--with-openssl=/usr' '--with-python=python3' '--enable-dnstap' '--enable-largefile' '--enable-linux-caps' '--enable-shared' '--enable-static' '--disable-isc-spnego' 'build_alias=x86_64-alpine-linux-musl' 'host_alias=x86_64-alpine-linux-musl' 'CC=gcc' 'CFLAGS=-Os -fomit-frame-pointer -D_GNU_SOURCE' 'LDFLAGS=-Wl,--as-needed' 'CPPFLAGS=-Os -fomit-frame-pointer'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1c  28 May 2019
linked to OpenSSL version: OpenSSL 1.1.1c  28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with libjson-c version: 0.13.1
linked to libjson-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled

default paths:
  named configuration:  /etc/bind/named.conf
  rndc configuration:   /etc/bind/rndc.conf
  DNSSEC root key:      /etc/bind/bind.keys
  nsupdate session key: /var/run/named/session.key
  named PID file:       /var/run/named/named.pid
  named lock file:      /var/run/named/named.lock

Steps to reproduce

Setup another server that supports SINK (or mock it up).
Do a query for dig SINK example.com
The answer is interpreted (and displayed) as <meaning> <coding> <subcoding> <data>

What is the current bug behavior?

The SINK RR is defined as

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    MEANING    |     CODING    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   SUBCODING   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// DATA ...                    //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What is the expected correct behavior?

The spec defines it as

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    CODING     |  SUBCODING    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// DATA ...                    //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Relevant configuration files

$TTL    604800
@               IN    SOA     bind.test. nsmaster.bind.test. 1 604800 86400 2419200 604800
@               IN    NS      ns.bind.test.
ns              IN    A       127.0.0.1
ns              IN    AAAA    ::1 

sink            IN    SINK 0 65 2 Test  ; This is the current form to define SINK RR
sink            IN    SINK 65 2 Test    ; This should be the correct form according to the spec

Relevant logs and/or screenshots

$ dig @localhost -p5301 SINK sink.bind.test +short
0 65 2 Test