[rfc-i] v3imp #6 Byte preservation for figs

Sean Leonard dev+ietf at seantek.com
Sun Jan 25 13:06:24 PST 2015


On 1/25/2015 1:19 AM, Leonard Rosenthol wrote:
> On 1/23/15, 9:18 PM, "Sean Leonard" <dev+ietf at seantek.com> wrote:
>
>
>
>> The term "attachment" captures what I am looking for reasonably well.
>>
> Would these be “attached” to the object where they are defined or would
> they be “attached” strictly to the entire document?  Or doesn’t it matter,
> since that might be considered a matter of presentation?

Good question...I did not think about this too much until your e-mail.

It could go either way. I think it makes more sense to make attachments 
be companions to the document, and therefore, attached to the entire 
document, such as in an <attachments> optional block towards the end of 
the <rfc>. However in my proposals prior to this e-mail, I also 
envisioned that they could be attached to the object in which they are 
defined, namely as a drop-in replacement for <figure> or <artwork>. 
(PDFs present attachments in the former manner; Word/Office documents 
present attachments in the latter manner; e-mail clients do both.)

<attachment> (or similar) in my formulation is supposed to be used for 
things that currently are a) in appendices, or b) in example sections, 
particularly large appendices/examples where keeping them inline is a 
big waste of paper (printed) or scrolling capacity (digital), or where 
formatting down to the byte is particularly important.

I fished randomly in the RFC 72xx range...one example that might be 
appropriate is Figure 9 of RFC 7250, Appendix A:

*********


    Appendix A <http://tools.ietf.org/html/rfc7250#appendix-A>. Example
    Encoding



    For example, the hex sequence shown in Figure 9 describes a
    SubjectPublicKeyInfo structure inside the certificate payload.

           0     1     2     3     4     5     6     7     8     9
       +------+-----+-----+-----+-----+-----+-----+-----+-----+-----
    1  | 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48,
    2  | 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81,
    3  | 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd,
    4  | 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13,
    5  | 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f,
    6  | 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c,
    7  | 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb,
    8  | 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b,
    9  | 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60,
    10 | 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6,
    11 | 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa,
    12 | 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7,
    13 | 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2,
    14 | 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34,
    15 | 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91,
    16 | 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01,
    17 | 0x00, 0x01

       Figure 9: Example SubjectPublicKeyInfo Structure Byte Sequence

    The decoded byte sequence shown in Figure 9 (for example, using Peter
    Gutmann's ASN.1 decoder [ASN.1-Dump  <http://tools.ietf.org/html/rfc7250#ref-ASN.1-Dump>]) illustrates the structure, as
    shown in Figure 10.

    Offset  Length   Description
    -------------------------------------------------------------------
       0     3+159:   SEQUENCE {
       3      2+13:     SEQUENCE {
       5       2+9:      OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1)
                  :             PKCS #1, rsaEncryption
      16       2+0:      NULL
                  :      }
      18     3+141:    BIT STRING, encapsulates {
      22     3+137:      SEQUENCE {
      25     3+129:        INTEGER Value (1024 bit)
     157       2+3:        INTEGER Value (65537)
                  :        }
                  :      }
                  :    }

        Figure 10: Decoding of Example SubjectPublicKeyInfo Structure


*********

In this case, Figure 9 is not particularly actionable: it uses a custom 
grid format and basically requires an implementer to do a lot of 
deleting and splicing, or develop an algorithm to do the same. Figure 10 
in contrast is clearly understandable as an inline figure.


With <attachment>, Appendix A could look like:

*********


    Appendix A <http://tools.ietf.org/html/rfc7250#appendix-A>. Example
    Encoding



    For example, Attachment 1 is the DER-encoded SubjectPublicKeyInfo
    structure inside the certificate payload.
    The decoded byte sequence (for example, using Peter
    Gutmann's ASN.1 decoder [ASN.1-Dump  <http://tools.ietf.org/html/rfc7250#ref-ASN.1-Dump>]) illustrates the structure, as
    shown in Figure 10.

*********

Attachment 1 is at the end:
<attachments>
<attachment src="spki.der" type="x.690" name="spki-example.der" />
</attachments>


Alternatively, Appendix A could look like:
*********


    Appendix A <http://tools.ietf.org/html/rfc7250#appendix-A>. Example
    Encoding



    For example, Attachment 1 is a
    SubjectPublicKeyInfo structure inside the certificate payload.

    -----------------\
    |                 \
    |                  \
    | spki-example.der |
    |                  |
    |                  |
    --------------------
    Attachment 1: Example SubjectPublicKeyInfo Structure

    The decoded byte sequence of Attachment 1 (for example, using Peter
    Gutmann's ASN.1 decoder [ASN.1-Dump  <http://tools.ietf.org/html/rfc7250#ref-ASN.1-Dump>]) illustrates the structure, as
    shown in Figure 10.

*********

Attachment 1 replaces <figure>:

<t>For example, <xref target="spki-example.der" /> is a 
SubjectPublicKeyInfo structure inside the certificate payload.</t>
<attachment src="spki.der" type="x.690" name="spki-example.der" 
caption="" />
<t>The decoded byte sequence of <xref target="spki-example.der" /> (for 
example...)...</t>


Between these two examples, I consider the former to be superior. 
Unnecessary space is not devoted to a blob that users can't 
comprehend--or aren't expected to comprehend--directly, as evidenced by 
the illustration in Figure 10. It is just as easy for a screen reader to 
highlight "Attachment 1" in the former case as a link, which will then 
transport the user to that particular file/binary sequence.

...but either one ultimately is fine, if that's how consensus goes. Both 
are reasonable ways to make use of the proposed <attachment> type of 
element.

Sean



More information about the rfc-interest mailing list