Re: [Cbor] John Scudder's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

[Michael Richardson <[e-mail]>]

Hi John, thank you for your comments.

John Scudder via Datatracker <[e-mail]> wrote:
    > Thanks for this document. It seems useful, and the core specification
    > part in Section 2 is clear and understandable.

    > That said, it could be even friendlier to someone approaching it as a
    > CBOR n00b. I don't think that's a major concern, because I can’t
    > imagine why someone other than a hapless IESG member would approach
    > this document cold, without some reasonable background in CBOR. Still,
    > if you want an example of what I'm talking about, the casual "so that
    > there are no leading zeroes" in Section 2.1, with no whys or
    > wherefores, felt a bit like a scavenger hunt.

I think that the changes that Carsten has proposed already address all of
your concerns.
https://github.com/cbor-wg/cbor-magic-number/pull/21/files

    > Finally, I do have one specific comment on where the text is unclear in
    > Section 2.2:

    }    A CBOR Protocol specification may specify the use of two tags only
    } for specific cases.  For instance, it might use them when storing the
    } representation in a local file or for Web access, but not when using
    } them in protocol messages that already provide the necessary context.

I think that this should perhaps read:

    }    A CBOR Protocol specification *might* specify the use of the
    } *Enveloping Method* only
    } for specific cases.  For instance, it might use them when storing the
    } representation in a local file or for Web access, but not when using
    } them in protocol messages that already provide the necessary context.

    > The first sentence reads like a prohibition on specification of two
    > tags for general cases. (I don't know what that would mean, it's just a
    > straightforward way to parse it. "May" combined with "only" is the
    > difficult bit I think.) If your meaning is what I think it is,
    > substituting "might" for "may" would fix it.

Here we are putting some kind of soft requirement on other document writers.

I've never been clear if that's normative language or not.  Generally, I
think it isn't.

I agree, that might works better in the first line.

This paragraph has mutated a few times in the last few revisions, I'm gonna
sleep on it.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-