[Cbor] some last minute minor comments on cbor-packed-07

[Michael Richardson <[e-mail]>]

I read packed-07 from top to bottom today.
(I had a headache, and other things were too difficult. It was on my todo
from IETF114... so...)   I recognize that I've missed the WGLC.

In the introduction, the term "rump" is used before it is defined.
Actually, it's also not in the terminology section.
The term was new to me in this work, perhaps it's common in compression
algorithm descriptions.  I think that the rump is the uncompressable original
data.

The introduction introduces two kinds of thing:
  * item sharing
  * argument sharing

The terminology defines:
* _Shared item reference_
* _Argument reference_

Maybe the introduction could align better with the terminology?
In particular, since:
   "A specific application protocol that employs Packed CBOR might allow both
   kinds of optimization or limit the representation to item sharing only. "

other protocols are going to need to be specific, it should be easy to
find/search the specific terms, I think that the terms should be very clear.

(I suggest "specific CBOR application protocol", btw)

}  and, in the HTML and PDF versions, subtraction and negation are rendered
}  as a hyphen ("-", as are various dashes).

I guess because in HTML and PDF, there is a distinction between hyphen and
minus, while the text version, there isn't?

2.2:
} Note also that the tag content of Tag 6 may itself be packed, so it may
} need to be unpacked to make this determination.

I feel that perhaps this deserves it's own paragraph.  Maybe even it's own
subsection!

Inversion imples 1/thing to me (thus inverted), but in this document, it
means to swap the order of the arguments to the function.   If there was
another term for argument swapping I would suggest it, but I don't have one
handy.

} Note that table index 0 of the argument table can be referenced both with
} tag 6 and tag 224, however tag 6 with an integer content is used for shared
} item references (see Table 1), so to combine index 0 with an integer rump,
} tag 224 needs to be used.

I think that this needs a few extra words for those of us more dense.

section 2.4
} If both left hand side and right hand side are one of the string types (not
} necessarily the same), the bytes of the left hand side are concatenated
} with the bytes of the right hand side. Byte strings concatenated with text
} strings need to contain valid UTF-8 data.

Seems like there is a SHOULD or MUST here.
What does an unpacker do if it is not valid UTF-8?
Should it even check?   For some environments (Rust, Python, sometimes Ruby),
they can't by construction even safetly return invalid UTF-8 strings, so
sometimes the check will be forced, or hard to avoid.

} Table setup can happen in one of two ways:

} By the application environment, e.g., a media type.

So one situation where table might be incomplete is when the protocol is versioned.
Does this warant specific text?

} (The specific behavior of any such tag, in the presence of a table applying
} to it, needs to be carefully specified.)

It seems like this sentence is anticipating new text, which hasn't occured
yet.  So maybe it's supposed to be a forward reference?
Or maybe I do understand this part.

Could section 4.1 examples be numbered?

I don't understand why in the first example, the argument list has 106(),
while in the second example it does not.  Then tag 216 pops up...
I think that the naive reader needs a bit more help at this point.
Maybe just a reminder that tag 6 is straight rump, table index 0,
and that 216 is table index 0, inverted.

I think also that there are two unpacks that occur, and maybe that either
needs to be drawn out as an example, or not be the first example.

I did not grok Tag Equivalency.
I will try reading it again tomorrow.











--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide