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

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 1 Mar 2021 18:20:22 +0100

Hi Alice,

Considering both examples, it looks to me like <dl> is the best fit.

Best,	Henrik

On 2021-02-27 00:22, Alice Russo wrote:
> 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.
>

---

From: Alice Russo <[email-masked]>
Date: Mon, 1 Mar 2021 16:38:03 -0800

Hi Henrik,
Thanks for your reply; we'll proceed accordingly.

Alice

> On Mar 1, 2021, at 9:20 AM, Henrik Levkowetz <[email-masked]> wrote:
> 
> Hi Alice,
>