That's unhelpful to the degree that if it's any indication of MessagePack people's behaviour back then, I can see why the IETF would ignore the input.
I understand it's not easy to find things there, I tried, and I understand you might not want to spend the time to dig things up. I primarily asked since I hoped you could call something up by remembering some searchable content. If you can't, just say so and that's fine. Throwing that link at me is just rude.
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.
That's unhelpful to the degree that if it's any indication of MessagePack people's behaviour back then, I can see why the IETF would ignore the input.
I understand it's not easy to find things there, I tried, and I understand you might not want to spend the time to dig things up. I primarily asked since I hoped you could call something up by remembering some searchable content. If you can't, just say so and that's fine. Throwing that link at me is just rude.
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.
2 replies →