Re: [Cbor] [cbor-wg/cbor-magic-number] WGLC review (#10)

[Michael Richardson <[e-mail]>]

John Mattsson <[e-mail]> wrote:
    > I provided I review as requested during the last IETF meeting. I just
    > looked at -04 as I plan to use this for C509. Seems like you might have
    > missed the mail with my review so I repost it here. Use it as you wish.

    > https://mailarchive.ietf.org/arch/msg/cbor/mxVhcytAIBgPqMCGwlQwXYZiOOo/

I'm sorry that I missed your July 31st review.
I don't think that posting it to the github is the best way.

    > - "as is a file extension" The draft does not say anything about how to
    > chose a file extension. I think the needs to say something and give
    > guidance. Are protocols supposed to use some generic ".cbor" or use
    > there own like ".c509". Is it recommended to use several tags with the
    > same extension, i.e., should .c509 be used for several different tags
    > (chain, bag, CSR, CRL,...) or should each tag use its own file
    > extension. In the later case it would be good if the file extension was
    > registered together with tag number in IANA.

I'm sorry, but it is not my intention to make any recommendations on file extensions.
I have no opinion.

    > - I think it would help the reader to have an examples (CBOR diagnostic
    > + CBOR encoding) already in Sections 3.1 and 3.2.  Something like the
    > example in appendix B: "55800(1330664270(h'424F52'))" Example CBOR
    > protocol values and the resulting bytes in the file would be even
    > better and would really help to make the draft easy to understand.

So, you'd like an example in this section.
I can do that.

    > Minor comments:

    > - "MacOS" The official spelling of the current version is "macOS"

    > - "classic MacOS..."  Earlier versions were "Mac OS", "Mac OS X", and
    > "OS X".

okay.

    > - "such as when attempting to do forensics on a damaged system" Is that
    > important enough to motivate additional bytes for Iot devices?

First, who said the damaged device was an IoT device, as opposed to the
system that was used to program/design the IoT device?
Second, IoT devices regularly have multiple megabytes of flash now.

    > - "ZIP files of XML files."  Also media and fonts etc.

Yes, so what would you like you say here?
That font files are also ZIP files?

    > - "artifacts" Is artifacts the right word here?

Yes.

    > - "A magic number is ideally a unique fingerprint, present in the first
    > 4 or 8 bytes of the file" "that results in a deterministic first 8 to
    > 12 bytes" You should explain why you did not chose the "ideal"
    > solution, or change the text on what is ideal.

I think that I did exactly that.

    > - Would be good with a sentence explaining that if the protocol is a
    > CBOR sequence then 3.1 cannot be used.

    > - "for each tag number NNNN, the representation of content-format
    > (RFC7252) NNNN-1668546560" I don't understand the ” NNNN-1668546560”
    > notation. Should it be NNNN + 1668546560 ?

No, because the tag number is NNNN, not the Content Format.
I changed it in a future version to NNNNNNNN to emphasis that it's the bigger number.
I also had to read this text twice to be sure.

    > - "Subregistry" RFC 8126 states that the term subregistry was
    > unfortunatly used in the past. I think "CoAP Content-Formats" is a
    > registry in the "Constrained RESTful Environments (CoRE) Parameters"
    > group.

Carsten?

    > - "00000000 d9 d9 f8 da 4f 50 53 4e 43 42 4f 52 |....OPSNCBOR|" I don’t
    > understand where the zeroes come from? Seems like postfix instead of
    > prefix.

000000000 is the offset in the file.

    > OLD "Both OpenOffice or MSOffice files" NEW "Both OpenOffice and
    > MSOffice files"

What's the change?

    > OLD "QRcode" NEW "QR code"

okay.

    > OLD "This new sequence of tags are" NEW "This new sequence of tags is"

okay.

    > OLD "the the use of CBOR" NEW "the use of CBOR"

already fixed.

    > OLD "private keys, certificate requests and S/MIME content."  NEW
    > "private keys, certificate requests, and S/MIME content."  (IETF use
    > the Oxford comma)

thanks.

    > OLD "certificate requests" NEW "certification requests" or "certificate
    > signing request"

RFC7030 calls thems Certificate Signing Requests.
RFC5280 does not use the term.
RFC4210 speaks of Certification Requests, but not CSRs.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [