>
>> https://cabo.github.io/cbor-media-types/draft-bormann-cbor-defining-media-types.html
>
>> 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.
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.)
> "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?
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.
> 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.
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
> new-fangled single-hop-over-building wiki.
> ("Go big, or go home")
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.
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
