Comment by camgunz
5 months ago
All the links you want are in the post I made that was linked by TFA (IETF very annoyingly killed its URLs for some reason so you have to wayback machine a little). That, plus trying to argue IETF doesn't design by committee (which if anyone knows anything about IETF it's that) has made me assume you're just trolling me. If not, sorry! But what are you trying to add to the conversation here? Is your argument "IETF good, get involved"? It turns out someone can take yr serialization format, rename it, and standardize it entirely without your consent, so no thank you.
I'm happy to discuss stuff, even (especially) in depth, even to be your entree into this whole thing, but you gotta meet me halfway. This whole thread is me saying "hey that's my post!" Please start there.
Actually what happened here is that I saw the first small-grey-text paragraph, dismissed it as not interesting, saw the second such paragraph, dismissed that as well, and when it came to the 4th one which contains the links you're referring to I was in auto-dismiss mode. After your saying the links are in the article, I had to reread it twice until I found the links.
I now see there's been a bunch of back and forth. Good. (in a sense)
The IETF is not a committee process and your claim of "which if anyone knows anything about IETF it's that" is very likely something coloured by your bubble and context. Committee means the members of the standard body itself design things. The IETF doesn't even have members. It's the most open standards body I'm aware of (no idea how W3C works though, maybe they're even better.)
The IETF looks like a committee if you contrast against working without any standardization process, e.g. single project github protocol development. This works until it doesn't. It looks like MessagePack sat on making a string type/tag for more than 2 years; I don't know the story but that's not great either way. I've found a bunch of discussion now and honestly I can empathize with both "sides". What I don't understand is the hostility at the fork. IETF people needed something for use in other protocols, with a standards doc to reference. They had a choice of either making up something completely new, or base it on an existing design. They acknowledged MessagePack as a good design and extended upon it to fix issues, after those weren't addressed there. What's the problem?
And of course it's not compatible. It's not intended to be, it's not MessagePack, just MessagePack-derived.
> It turns out someone can take yr serialization format, rename it, and standardize it entirely without your consent, so no thank you.
That's the most pessimistic view possible, and ignores that changes were made. An optimistic view would be, someone acknowledged your serialization format as good, extended upon it, and took on the hassle to standardize it.
> The IETF is not a committee process and your claim of "which if anyone knows anything about IETF it's that" is very likely something coloured by your bubble and context. Committee means the members of the standard body itself design things.
There's no reward to this argument. I concede there's no actual committees. OK how do I add an "address" type to CBOR, that's right, I email a lot of people on IETF mailing lists, try and build support among people who have influence, spec authors feel persuaded/pressured, spec changes. This is a distinction without a difference, and is what almost everyone really means when they say "design by committee".
> What I don't understand is the hostility at the fork.
MP creators asked Bormann repeatedly to not submit anything to the IETF, and then to withdraw what he did submit. That wasn't cool of him!
> IETF people needed something for use in other protocols, with a standards doc to reference.
"needed" isn't the right verb here.
> They had a choice of either making up something completely new
That's fine. Or they could have waited. I think MPv5 came out like, a few months after Bormann's 1st draft (I'm guessing I don't really know). It's not like there was real urgency here. Nothing the IETF does is urgent.
> They acknowledged MessagePack as a good design and extended upon it to fix issues
CBOR's spec literally includes a section about MP [0] which was wrong when it was written and has become more wrong as time passes. Also not cool!
> That's the most pessimistic view possible, and ignores that changes were made. An optimistic view would be, someone acknowledged your serialization format as good, extended upon it, and took on the hassle to standardize it.
The changes were universally very bad, there was a good chance of causing huge confusion with slightly different very similar differently named formats, and there was an existing community of implementations. Imagine coming up w/ a pretty good data serialization format, building a company around it, fostering a diverse community of implementations, and some dude comes by, submits a similar yet incompatible version for standardization, adds a bunch of bad things to it, disses you in the spec, and names it after himself. What did standardization get them?
[0]: https://datatracker.ietf.org/doc/html/rfc8949#name-messagepa...
> OK how do I add an "address" type to CBOR, that's right, I email a lot of people on IETF mailing lists, try and build support among people who have influence,
It's normally about getting rid of complaints rather than building support, and the "people who have influence" thing is not entirely untrue but also not quite true either (I'm not willing to spend the time to go into this here.)
> spec authors feel persuaded/pressured, spec changes.
No, you'd publish a new document describing your extension; existing IETF documents never change and previous authors can't do jack shit other than writing sad mails on the mailing lists.
> This is a distinction without a difference, and is what almost everyone really means when they say "design by committee".
idk, I guess I'm not "almost everyone". For me, design by committee means the following things:
The IETF is none of these things.
> MP creators asked Bormann repeatedly to not submit anything to the IETF, and then to withdraw what he did submit. That wasn't cool of him!
I'll (sadly) agree that from the stuff I've seen by now that certainly wasn't done well.
> > IETF people needed something for use in other protocols, with a standards doc to reference.
> "needed" isn't the right verb here.
IMHO it is; CBOR was standardized in order to get used in a whole bunch of IoT RFCs. RFCs can certainly reference external specifications, the barrier here is that the same people that bash the document itself also need to be happy with its references.
> That's fine. Or they could have waited. I think MPv5 came out like, a few months after Bormann's 1st draft (I'm guessing I don't really know).
I mean, sure, but at that point it was already 2 years of trying to get string encoding into MessagePack? I think it's reasonable that at some point people give up…
> It's not like there was real urgency here. Nothing the IETF does is urgent.
This is sadly very untrue, e.g. the homenet stuff died because it did not get ready in time for incorporation into CableLabs CPE specs, and as a result of that now no normal CPE on the planet is IPv6 multi-router or multi-uplink capable. I don't know enough about the IoT stuff back then to say anything about urgency there.
> CBOR's spec literally includes a section about MP [0] which was wrong when it was written and has become more wrong as time passes. Also not cool!
Yeah that should've been updated when RFC 8949 superseded 7049.
As far as your last paragraph is concerned, I don't have the background to agree or disagree on the changes being "universally bad", have no idea what the risk of confusion was (there seems to be none now), will certainly agree that the naming choice is pretty poor, and as far as the "forked idea" is concerned, that's a personal-political opinion about ownership of ideas and concepts.
(And I think I've just about run out of time I want to spend on this. Thanks for your notes!)