<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version  (Ruby 3.1.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-amsuess-cbor-packed-by-reference-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title>Packed CBOR: Table set up by reference</title>
    <seriesInfo name="Internet-Draft" value="draft-amsuess-cbor-packed-by-reference-01"/>
    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization/>
      <address>
        <postal>
          <country>Austria</country>
        </postal>
        <email>christian@amsuess.com</email>
      </address>
    </author>
    <date year="2023" month="July" day="11"/>
    <workgroup>cbor</workgroup>
    <keyword>cbor</keyword>
    <keyword>packed</keyword>
    <keyword>uri</keyword>
    <keyword>cri</keyword>
    <abstract>
      <t>Packed CBOR is a compression mechanism for Concise Binary Object Representation (CBOR)
that can be used without a decompression step.
This document introduces a means for setting up its tables
by means of dereferencable identifiers,
and introduces a pattern of using it without sending long identifiers.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>[ See abstract. ]</t>
    </section>
    <section anchor="setting-up-the-tables-by-reference">
      <name>Setting up the tables by reference</name>
      <t>CBOR tag TBD114 is defined with semantics similar to
tags TBD113 and TBD1113 from <xref target="I-D.ietf-cbor-packed"/>
in that it sets up tables around a rump.</t>
      <sourcecode type="cddl"><![CDATA[
Packed-By-Reference = #6.114([count, source, rump])
rump = any
source = CRI / URI
count = (count-shared-and-argument //
  count-shared, count-argument //
  skip-shared, count-shared, skip-argument, count-argument)
count-shared-and-argument = int
count-shared = int
count-argument = int
skip-shared = int
skip-argument = int
]]></sourcecode>
      <t>The items inserted by the tables are not given explicitly,
but picked out of tables known by their identifier given as <tt>source</tt>.
Such a source needs to represent two lists of CBOR items,
one for each kind of tables.
The tag prepends some number of items out of those source lists
to the tables that are used to decompress the rump.</t>
      <t>The identifier is given as a URI string (as defined in <xref target="RFC3986"/>
or equivalently as a CRI (as defined in <xref target="I-D.ietf-core-href"/>.
Later iterations of this document may introduce additional options.
When the source identifier is dereferencable,
all considerations from <xref target="I-D.bormann-t2trg-deref-id"/> apply.
(Simplifying: No dereferencing at runtime -- the recipient either knows it already or treats it as unknown).</t>
      <t>If the same number of items is prepended to both tables,
their count is given as a single number;
otherwise, the numbers are given separately.
If a large number of items at the beginning of the source tables would not be used,
the four-argument form of count
defines a number of items in the source tables that are skipped
before selecting items into the table.
This allows keeping the indices low and therefore compact.</t>
      <t>Source tables should be designed in such a way
that commonly used items are at the start
to avoid the necessity of the four-argument form.</t>
      <t>There is no short-hand for importing all the items,
as the use of such a form would rule out any extensibility in source tables.</t>
      <section anchor="example">
        <name>Example</name>
        <t>Suppose the URI "tag:example.com,2023:byref" defines the items
<tt>["price", "category", "author", "title", "fiction", 8.95, "isbn"]</tt> in both tables.
Then the example in figure 3 of <xref target="I-D.ietf-cbor-packed"/> can be written as:</t>
        <sourcecode type="cbor"><![CDATA[
114([7, "tag:example.com,2023:books"
    [{"store": {
       "book": [
         {simple(1): "reference", simple(2): "Nigel Rees",
          simple(3): "Sayings of the Century", simple(0): simple(5)},
         {simple(1): simple(4), simple(2): "Evelyn Waugh",
          simple(3): "Sword of Honour", simple(0): 12.99},
         {simple(1): simple(4), simple(2): "Herman Melville",
          simple(3): "Moby Dick", simple(6): "0-553-21311-3",
          simple(0): simple(5)},
         {simple(1): simple(4), simple(2): "J. R. R. Tolkien",
          simple(3): "The Lord of the Rings",
          simple(6): "0-395-19395-8", simple(0): 22.99}],
       "bicycle": {"color": "red", simple(0): 19.95}}}]])
]]></sourcecode>
      </section>
    </section>
    <section anchor="nested-table-setups">
      <name>Nested table setups</name>
      <t>Assembling tables from one or more source references
can easily become verbose.
A pattern that reduces the verbosity
while staying unambiguous
are nested table setups,
where the outer tables are extended to contain additional identifiers.</t>
      <t>In this pattern,
tables are set up in two stages:</t>
      <t>The outer stage contains the CRIs or URIs that may later be used as source values.
(It may also contain other items).
Those tables may be set up in a way that grows over time,
so that more identifiers can be added later.
The inner stage is set up using tag TBD114,
and the source given is a packed reference.</t>
      <t>In this example,
the initial table set up is provided by the media type,
and contains these items:</t>
      <ul spacing="normal">
        <li>0: "This class has students with the following names"</li>
        <li>100: "tag:example.com,2023:english-names.txt"</li>
        <li>101: "tag:example.com,2023:german-names.txt"</li>
      </ul>
      <sourcecode type="cbor"><![CDATA[
114([5, 6(100) / outer item 100 /, 114([2, 6(106) / outer item 101 /, [
  6(11) / outer item 0, "This class has students with the following names" /,
  6(0) / item 0 of german-names, "Franz" /,
  6(2) / item 0 of english-names, "George" /,
  6(1) / item 1 of german-names, "Fritz" /,
  6(7) / item 5 of english-names, "Jack" /
  ]])])
]]></sourcecode>
      <t>When either the outer list gets extended (to add more source identifiers)
or any of the referenced source lists gets extended,
decoders can treat values as undefined
if their protocol allows such behavior.</t>
      <t>Note that a constrained implementation of a decoder
may not even have the fully expanded form of the URIs or CRIs available;
it may only be capable of using these table entries in the source position
and then find the shipped source lists.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>[ TBD ]</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>[ TBD: Request tag. ]</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="I-D.ietf-cbor-packed">
        <front>
          <title>Packed CBOR</title>
          <author fullname="Carsten Bormann" initials="C." surname="Bormann">
            <organization>Universität Bremen TZI</organization>
          </author>
          <date day="10" month="July" year="2023"/>
          <abstract>
            <t>   The Concise Binary Object Representation (CBOR, RFC 8949 == STD 94)
   is a data format whose design goals include the possibility of
   extremely small code size, fairly small message size, and
   extensibility without the need for version negotiation.

   CBOR does not provide any forms of data compression.  CBOR data
   items, in particular when generated from legacy data models, often
   allow considerable gains in compactness when applying data
   compression.  While traditional data compression techniques such as
   DEFLATE (RFC 1951) can work well for CBOR encoded data items, their
   disadvantage is that the receiver needs to decompress the compressed
   form to make use of the data.

   This specification describes Packed CBOR, a simple transformation of
   a CBOR data item into another CBOR data item that is almost as easy
   to consume as the original CBOR data item.  A separate decompression
   step is therefore often not required at the receiver.


   // The present version (-09) provides two table setup tags (common,
   // split setup) and discusses behavior in case of references to
   // unpopulated table entries during unpacking.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-cbor-packed-09"/>
      </reference>
      <reference anchor="I-D.bormann-t2trg-deref-id">
        <front>
          <title>The "dereferenceable identifier" pattern</title>
          <author fullname="Carsten Bormann" initials="C." surname="Bormann">
            <organization>Universität Bremen TZI</organization>
          </author>
          <author fullname="Christian Amsüss" initials="C." surname="Amsüss">
         </author>
          <date day="9" month="May" year="2023"/>
          <abstract>
            <t>   In a protocol or an application environment, it is often important to
   be able to create unambiguous identifiers for some meaning (concept
   or some entity).

   Due to the simplicity of creating URIs, these have become popular for
   this purpose.  Beyond the purpose of identifiers to be uniquely
   associated with a meaning, some of these URIs are in principle
   _dereferenceable_, so something can be placed that can be retrieved
   when encountering such a URI.

   The present -00 version is a stub to draw some attention to the
   opportunity that this pattern would benefit from a common
   description, documenting its benefits and pitfalls, and some
   mitigations for the latter.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-bormann-t2trg-deref-id-01"/>
      </reference>
      <reference anchor="RFC3986">
        <front>
          <title>Uniform Resource Identifier (URI): Generic Syntax</title>
          <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
          <author fullname="R. Fielding" initials="R." surname="Fielding"/>
          <author fullname="L. Masinter" initials="L." surname="Masinter"/>
          <date month="January" year="2005"/>
          <abstract>
            <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="66"/>
        <seriesInfo name="RFC" value="3986"/>
        <seriesInfo name="DOI" value="10.17487/RFC3986"/>
      </reference>
      <reference anchor="I-D.ietf-core-href">
        <front>
          <title>Constrained Resource Identifiers</title>
          <author fullname="Carsten Bormann" initials="C." surname="Bormann">
            <organization>Universität Bremen TZI</organization>
          </author>
          <author fullname="Henk Birkholz" initials="H." surname="Birkholz">
            <organization>Fraunhofer SIT</organization>
          </author>
          <date day="10" month="July" year="2023"/>
          <abstract>
            <t>   The Constrained Resource Identifier (CRI) is a complement to the
   Uniform Resource Identifier (URI) that represents the URI components
   in Concise Binary Object Representation (CBOR) instead of a sequence
   of characters.  This simplifies parsing, comparison and reference
   resolution in environments with severe limitations on processing
   power, code size, and memory size.


   // (This "cref" paragraph will be removed by the RFC editor:) The
   // present revision -13 of this draft picks up some additional
   // discussion points and is intended as input to the CoRE WG meeting
   // at IETF 117.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-core-href-13"/>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>[ TBD ]</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VY23LjNhJ9x1eg5Bc7JWosOZ6MlZqq9XhycSqZbNlO5cGZ
qgFJSMKaJBgClEfr0nzZvuXHcroBSqQvD7ubmoopsNE3nD7dYJIkYj2XJ0J4
4ws9l6N/quxO5/Li3a9Xc3mj0kJLp71sa5luZKMXutFVpkcit1mlSuzIG7Xw
iSpdq51LstQ2Sc06knST7DYkx1ORKa+XttnMpfO5EKZu5tI3rfOz4+Oz45m4
t83dsrFtPZekRtzpDZbyuZAyCSv0EJTzY9uY8A5/hWr9yjYQTrAmZXDuYtUY
542q5Hnp/vqPc/wus23lyY9zGG+M4kVdKlPAcrfjHzGkSWZLISrblMqbtSZv
LpP3E6P9oh9tt56SYFUlfuabZZIj+kVi+O3V9xcnZ29eDxXYRicryMyRj2qx
NyJEkiRSpfBPZV6I3rFI46RCDGXdwD1jK1nqbKUq40oJDfLCVplxWr4zlWo2
8tf0Xzrz8kqTuK48DGDLIWk6En6lvMyQnlTL1sHAvUEWWw8Due6bcF7XE3Gz
gm2cfFtCkTRIos3bTJM/pVaVY/uAizfVkiBjvJOeMOQE0BNE7EJyVhgXjC+T
Q5tZGN24sVBVPlRcK+91U9G+1pFe43deIp6clgpL63s1k5C+0uR5oYU4kJdR
I8UuxB+38lrrXXYn8o+PgqSu9577lY6eD3AvBJ+AV0t58+79dPo1HUauF6aK
uYNLOH5vMiedKU2hGumtgLwLG04kBciPeF40tpQPD8/habsFICSfj6FAkUly
K7ikUCVQo2TTljgW8eXLlwyhRpQk7zbJVeexfCsPXk/g6eEtw34snW2bTI95
78cjQX8gpKqNCG/w4+LqUr6Sv11dCt6DlUN+SNxKNTCAGBLVLAMMXr0SsaTi
63H8NZRwd6Z+JND94led9OPdR+Jl028JKoP3g6VHcj0P+iuPpJBLAaADll6X
DktONx47AIMeKKBEVtbLJaq1kvpzXZgMDLoZixS4rA1XK0EUsI1b7ip7X0U1
punBNSpRTn4KJ/BpIq7bbIXzjSdSaZ2jkiyAGKtY+nsrCzAVF1SgBfJ3LGyl
uQy1goY7A5jsXJhwXAReaKlROwCpLaG+LVO4AbkQc+f3yoJGogtsS8CFXhIY
nZQJpg6823MGi0V0cjL30aJidgErApkkEkbZHap9LQH7Dw+RMVEKFM+frVmr
AmqKTdhKKH2y5ym1brcT8TNaT0PRNUx/LoTXJ7NSbfa8I1WeGxJUhbQ175iI
31e64rBiRoYhDTkNPFYUAHLlINXZ7FX7811iu5WqrovNRBxemxKQWmyQl7n8
YHvqKVNIewOAG5wdaI5TrTNTGwpEg4XgEqHNEXWootEq30ik0OPJh0WwScWA
PMIBXS5CXOoZLCC0CJZwxKkFyYXzH4uA5MARw2Mlpi46bd8KSz7doyuN2VJY
DlUUNjldK+RJU/BwR0kw5/KpNwic9qd6aaqKMmEX/SOJuLy3bZFzeca2xp6i
KtpmX+3UbGk7ey8ChsjzJwmonrGwQz4xSI1xJNXQR6NSgWYbulTY3K+Y2EAB
DTqbO61rkqTXKFND7Q4vuEFQuoJGKijqUUJcDzxwKw4SAebamWXEvwu0ca82
sbXbsrQVCoYrNOYQWmMenVeNp6JWa2vycDQ6o5bvN11qn2YtlDS0IJbKkieN
T1bkNvEOgIvfjFKUgO+IFBURSAGekOroKZ9COK+mBWB49qg2YFSvUTypKcgV
iqwfPTw4OJDffVYoEvTk67auiapIPfHJCBQ31+EtjW/j2fHsZJ5ukNKR7E56
55n4dDuqG6R/NJajbkal5zBR0hMPx/SwMDxC4PHN5OwUC8al1ejjJ/KwVxlM
tAE30Q0SWJhli6ydUPgvNf1uGLtvDMYeKqZ5aO80/nIX/2b8UnzW3rkRz7K3
DyPngZ7RXD7wAv4b0Xss3HYLUj44Yhl9OD3C4L+f7ccyrs9o/YNZ6gLjo3aj
8X5rJ3JCIteKeMp1iLkAUFpOYRQ6hlB8PD3ajp93ID5+fTQ0/90anFDJ31W7
XL3sAN0TyPyPtgJOhpans8nZ2X9p9UdN/Cx/0cXaFHT0Lxj+xaKfv0e335t8
TevHyenpSTKbnkynyclzu/+flPw0kVf878YWd+D8F72jxvtzzAwdzBWd0nPS
0eeTs9Nkekb/fzNM4YxT+HG8x5LJNlnB+BpltkCVMILyR5k/Q5Fst9uPGDN5
rDqQH7SjYcp3F8u2dkKcO0zNacFkGNiNWyVNMiCUkok1lP8OpE5QoWjlDMgt
pbFDy7VuUtDARJzvLg1MgvCL7xKUgiADThH3K1MwA2545Md9MUV92tYJnu2e
+jnGFmI9UgOaQo/ozYLMV7FFou17hXrvDRHDu8llFYaP6CW6015RvGxT18GE
B/eWmijgZmeUlzobISgMQo4y9Rv95ZBpmil45ukudsp1OcQQ1RJFHV4GOVW4
vc/cqAMvHhGLMa0G70g27TvIfSbYw7UdHc2uKSmYSsa4SkRH6PB60Xf8htzA
KXYxTKXo57vgkJpoJdz49tetcD/s9eMwPZhwUeSheweRXqIjV4YxwFQ4FZyJ
73/c4DHHrk2+n/RLnRsl/abWwWo/5S72DpzMV/KYSw0askJh8l1Rqn1LMbtw
JwxtlLo+RUNfJsDTX8npMe18lss1pifjVgnLTvxnH+SnL8kvma/64sOmgVb1
+hD2jnCtCzAi98kD+WosWWQWRF4/EZmSCHUNvJ4+ens8/h9Chz7Wxt4ENcRQ
/Rig9vtGVf/eyc6GsoP8QPgHbTEu7qSnO+nps5qN32v+Zid7+pzmn4AqyEIU
LNbxGF8F4qC9pwO6IsGWd3s2OKTZKs8HHNarhiO62NC4Ewl6h918cO0aKh0L
umblXTHxUB+LOsz18T4kzCJeNYFsb0HT3eTJs1eqV2ptLMpPfLBex5GW7yy+
UeFCRSArd9+M7CJ+FoJtQWxAE7am+oOmwIuLtihoeKsVh9/N2HEwY5JislJr
ZQqqv2+FCSzEUyqIIVM11+Xuc0+otlCscKUx+vFMXhOh04edyA00aXUsseLx
fJDNSfjUk7UNjZYXgzsafxsC1fAXoQN5ef7h/AWJOUaiP5FyT+wUviDRJ6cU
cKGd5xndrgqdLyl/TjzMw71C529HCzCuHm37tv4GEx6Eg4gVAAA=

-->

</rfc>
