Subject: [Xml-sg-cmt] question: a table with notes beneath it

From: Alice Russo <[email-masked]>
Date: Fri, 26 Feb 2021 15:22:05 -0800

Hi team,
2 related questions below.

Example A:  What do you recommend for the element for the note "(1)" beneath the table? 

Original: Table 1 in https://tools.ietf.org/html/draft-ietf-suit-architecture-16.html  (also pasted at the end of this mail)

Options that come to mind:
1) <aside> 
Q: Is it accurate that the note is "semantically less important or tangential to the content that surrounds it"? (to quote the definition of <aside>)

2) <t> with keepWithPrev="true" 
(in the hope that it will be on the same page as the table in the PDF output)

3) <dl> where
<dt>(1):</dt><dd> A device presented with...</dd>

4) <sup> (for superscript) would look like a footnote in the HTML and PDF, as typical in some other publications, but appears as ^(1) in the TXT. e.g.,

 ^(1) A device presented with an old but valid manifest and firmware
 must not be tricked into installing such firmware since a
 vulnerability in the old firmware image may allow an attacker to gain
 control of the device.

(For full context, in v2 it was in <t>; after autoconversion to v3, it was still in <t>.)

----
Example B: In this case, it's a set of notes (or a legend). What element do you recommend?

Original: Figure 2 in 
https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-13.html

Edited:  (using #3 above <dl> for the legend)
https://www.rfc-editor.org/v3test/test-ietf-lwig-tcp-constrained-node-networks-13.html#name-summary

(For full context, in v2 the notes were part of the <artwork>; after autoconversion to v3, they of course were still part of <artwork>, but the RPC changed the table portion of the <artwork> to <table>.)

Thanks,
Alice
--

Example 1:
 +----------------------------+--------------------------------------+
 |                   Decision | Information Elements                 |
 +----------------------------+--------------------------------------+
 |  Should I trust the author | Trust anchors and authorization      |
 |           of the firmware? | policies on the device               |
 |                            |                                      |
 |      Has the firmware been | Digital signature and MAC covering   |
 |                 corrupted? | the firmware image                   |
 |                            |                                      |
 |   Does the firmware update | Conditions with Vendor ID, Class ID  |
 |      apply to this device? | and Device ID                        |
 |                            |                                      |
 |   Is the update older than | Sequence number in the manifest (1)  |
 |       the active firmware? |                                      |
 |                            |                                      |
 |     When should the device | Wait directive                       |
 |          apply the update? |                                      |
 |                            |                                      |
 |      How should the device | Manifest commands                    |
 |          apply the update? |                                      |
 |                            |                                      |
 |      What kind of firmware | Unpack algorithms to interpret a     |
 |              binary is it? | format.                              |
 |                            |                                      |
 | Where should the update be | Dependencies on other manifests and  |
 |                  obtained? | firmware image URI in Manifest       |
 |                            |                                      |
 |  Where should the firmware | Storage Location and Component       |
 |                 be stored? | Identifier                           |
 +----------------------------+--------------------------------------+

                  Table 1: Firmware Update Decisions.

 (1): A device presented with an old, but valid manifest and firmware
 must not be tricked into installing such firmware since a
 vulnerability in the old firmware image may allow an attacker to gain
 control of the device.