Subject: [dispatch] Creating CBOR-based media types and content formats

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Jul 2021 14:08:15 +0200

We had interesting discussions yesterday about how to fix the media-type and content-format registrations for CBOR-based anima vouchers.

I’m growing a bit tired of dispensing the ancient wizardry that is required each time such a registration is needed, so I started writing it up:

https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html

Comments and PRs very welcome.

I plan to submit this as a -00 on Sunday; probably too late for DISPATCH (but I wouldn’t mind some discussion over there as well).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jul 2021 18:14:25 -0400

Carsten Bormann <[email-masked]> wrote:
    > We had interesting discussions yesterday about how to fix the
    > media-type and content-format registrations for CBOR-based anima
    > vouchers.

Thank you for your input, and for trying to remove yourself from the loop.

    > I’m growing a bit tired of dispensing the ancient wizardry that is
    > required each time such a registration is needed, so I started writing
    > it up:

    > Comments and PRs very welcome.

I did find reading it invoked a new appreciation for Arcane Wizardry.

Specifically, I found that sections 3 and 4 didn't tell me anything that I
recognized as important for filing in the template.

  "The Encoding considerations are often used in a way that is different from
  the intention in Section 4.8 of [RFC6838], which is a simple selection
  between "binary" and various alternatives that are now all obsolete. "

so, really, it's always binary now?
Maybe, just say that somewhere.

I don't think you should hide the example in the appendix.

Rather, I think that you should make it the core of the document, explaining
each bit of arcana.  If it's worth publishing this as a new RFC, then it's
worth obsoleting RFC6838.  Otherwise, I suggest some nice HTML, maybe in the
new-fangled single-hop-over-building wiki.
("Go big, or go home")

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2021 02:37:29 +0200

> recognized as important for filing in the template.

Right, Section 2 is the one that is collecting the information about registration.
(Section 3 and 4 haven’t been written yet, anyway.  
I thought it would be a good idea to get Section 2 out as input for the ANIMA constrained voucher.
But it doesn’t discuss media type parameters yet, so it isn’t complete either.)

> so, really, it's always binary now?

Well, for CBOR-based protocols, yes.
If you have a JSON-based protocol that can only represent “true” and “false”, this might qualify for “7bit”.
(But if that protocol ever needs to be extended to alternatively carry, say, a number, you’d have to make a JSON-foreign rule of limiting the number to 999 characters, or you run into trouble with “7bit”.  
Once you add strings that can contain more than just enumerated ASCII values, you are solidly in binary land, as UTF-8 is “binary" in this selection.)

Here, the fact that MIME stands for Multimedia Internet *Mail* Extensions (where “Mail” means SMTP) comes through.

(I think you briefly brushed into that history with RFC 7030 EST, which is combining E-Mail Content-Transfer-Encoding with HTTP.  
[Utterly amazing how this could clear the IESG.]
You fixed that in RFC 8951, without making it entirely clear that you changed the meanings of the media types to now be base64-legacy, which by the way, with the right line breaks, is 7-bit...)

> Maybe, just say that somewhere.

I thought I did, but I certainly can make it more obvious.

> each bit of arcana.  

That sounds like a great project for long winter evenings at the fireside.
(Macintosh file type code(s)?  Fragment identifier considerations?)

(I forgot to encapsulate the example in ~~~ wiggles so you can copy-paste.)

> If it's worth publishing this as a new RFC, then it's
> worth obsoleting RFC6838.  

It has no normative intent (*) (and it doesn’t cover a tenth of 6838).

I do think that it will be worth publishing, after a lot of feedback has been obtained from the people who actually have been around when the arcana were invented.

I also think that the next update of 6838 might want to structure that template in a more meaningful way.

> Otherwise, I suggest some nice HTML, maybe in the

I think my parser is failing here.

Grüße, Carsten

(*) That is a lie: In fact, examples are always more normative than descriptive text, frantic disclaimers notwithstanding.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 22 Jul 2021 16:46:10 -0400

Carsten Bormann <[email-masked]> wrote:
    >> Rather, I think that you should make it the core of the document,
    >> explaining each bit of arcana.

    > That sounds like a great project for long winter evenings at the
    > fireside.  (Macintosh file type code(s)?  Fragment identifier
    > considerations?)

Yeah.
(I was cooling down in my unheated my pool last week, wondering why I can't
edit code while floating.  firesides would be other nice places)

    >> If it's worth publishing this as a new RFC, then it's worth obsoleting
    >> RFC6838.

    > It has no normative intent (*) (and it doesn’t cover a tenth of 6838).

okay, then Updates/Amends-6838, and replaces the template part then.

    >> Otherwise, I suggest some nice HTML, maybe in the new-fangled
    >> single-hop-over-building wiki.  ("Go big, or go home")

    > I think my parser is failing here.

I'm saying that if we aren't going to publish, then it goes into the new wiki.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-