Re: [apps-discuss] Concise Binary Object Representation (CBOR)

["Cullen Jennings (fluffy)" <[e-mail]>]

On May 24, 2013, at 8:23 PM, Phillip Hallam-Baker <[e-mail]> wrote:

> On Fri, May 24, 2013 at 7:11 PM, Cullen Jennings (fluffy) <[e-mail]> wrote:
> 
> Phil,
> 
> I think your email is out of line and that behavior like this is the largest threat to the IETF begin relevant in the future. If we treat people like this, they are going to take their work elsewhere. I've talked to people about why they don't bring standards work to the IETF and the list of reasons why is surpassingly short and pretty well illustrated by this thread.
> 
> Cullen
> 
> I was responding to Paul Hoffman. I hardly think he is quite the shrinking violet you suggest or a novice likely to be deterred from IETF involvement. He certainly isn't going to be deterred by anything I say. 

Agree and Carsten also is certainly capable of knocking me into line when I am wrong so I realize they are both experienced and not likely to be scared away from  the IETF by anything one person says. But it can still be frustrating, demotivating, and suck all the energy away from getting the technical work done. 

> 
> In particular I was responding to his rather premature claim that the difference between his proposal and the others was IETF 'consensus'. We have had all of two days discussion of this proposal while the MongoDB folk have a whole community built around theirs. 
> 

Ok - I don't think I saw them saying this had IETF consensus - clearly they don't. I do think that it makes sense for them to try and develop consensus around a solution that meets a broader sets of needs than what Mongo does.  That does not make what mongo is doing wrong for mongo but it is one of the reasons why there are a variety of ways of doing binary encoding of data that have evolved over time as the requirements, constraints, and target deployment environments have changed. 

> 
> More generally, one of the reasons I see people not wanting to bring work to IETF is the not invented here attitude. I was more than a little annoyed when the IETF response to SOAP was to quick march BEEP to proposed standard in an attempt to trump W3C and OASIS and so were many others. 

I generally agree that the IETF does better when it takes more than one community of interest and helps bridge them to create a more general and widespread solution that works for both. And sure I see lots of people proposing, lets have the IETF reinvent X - we are going to have some of both of these behaviors and at times it is a good thing. 

Some times I am happy when the IETF effectively rubber stamps a Cisco or Microsoft or some open source projects technology. Other times I am very happy when they do not rubber stamp it but instead look at the underlying needs and take a more multiparty collaborative approach. Both have their time and place to achieve the real goal of making the internet work.  



> 
> 
> On May 23, 2013, at 2:14 PM, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> > On Thu, May 23, 2013 at 3:24 PM, Paul Hoffman <[e-mail]> wrote:
> > On May 23, 2013, at 11:35 AM, James M Snell <[e-mail]> wrote:
> >
> > > That's well and good, from everything I've seen so far in this thread,
> > > the collective majority opinion can be summarized as "Ugh... Groan..
> > > Another one? Really?"
> >
> > Just a note that this is one of the only ones that people are groaning about that has an Internet Draft and might go through the IETF consensus process. Carsten and I (maybe naively) thought that doing this in this environment, instead of say posting ephemeral specs on a web page and not having it be clear where the community fit it, was a good thing.
> >
> > I don't remember you being appointed to address the issue.
> 
> Actually, I think you, and the rest of the IETF did appoint them. We encourage people to bring good technical work and discuss it. Clearly binary encodings is an important topic for IETF protocols - This seems like a perfectly reasonable list to bring the email discussion to.
> 
> I did not object to it being brought to the list. What I objected to was the claim of IETF consensus as the distinctive advantage for the protocol.
> 
> The IETF does have a body that is officially tasked with such things although it doesn't actually do that work. It is called the IAB. Paul's argument would make sense if it was being made by a member of the IAB tasked with driving us towards consensus on a binary encoding. Absent an explicit appointment to address the issue Paul's proposal is just another Internet Draft.
> 
> 
> What I interpreted the majority of the comments preceding it to be saying was 'why not document one of the existing specs' which is of course what was done with JSON itself. Instead we have a completely new proposal with no deployed base being proposed and the only advantage to this proposal is that it has an Internet Draft.
> 
> If the only problem with BSON etc is that they are ephemeral then making them concrete might be a good start. If there are other problems then a description would be useful.
> 
>  
> > Since almost all the response to your proposal has been that people don't like your design choices, and since you make it abundantly clear that you are not interested in our input, I can't quite see where a consensus is going to come. Unless that is the consensus is that your proposal sucks.
> 
> That was not my read of the thread so far.
> 
> I saw several people raise requirements, all I saw was pushback of the form 'we have decided to do it our way'. I have not seen any of the design choices being justified against requirements. I have not seen a technical argument being made for any of the choices other than for the counted vs delimited issue whare the answer was 'because'.
> 
> 
> "Use an existing scheme" would be a perfectly reasonable proposal. 
> 
> "Develop a new scheme based on requirements proposed by IETF community and those in the BSON etc community" would also be a reasonable proposal.
> 
> "Use our scheme, it has an Internet Draft" does not seem to be a reasonable proposal. 
> 
>  
> > I would certainly object to a format that was counted being granted any degree of IETF recognition lest someone try to force me to use it in the future.
> 
> This is not BCP that must be used by all future IETF protocols. It's an option for work that gets consensus to use it.
> 
> I don't believe that for two reasons.
> 
> First I have heard that exact statement used before about many similar projects and then I have sat in rooms where the people who said that use would not be mandated are telling another group that they are expected to use it. Remember when people were being told that they had to use BEEP for their Web service? I do.
> 
> Second, this particular spec is like JSON in that it only has value if everyone uses the same thing. There really is not room for more than one binary encoding of JSON in IETF. 
> 
> 
> JSON was originally an informational RFC. If we are going to have a binary encoding then we should probably follow the same approach and that candidates should be published as informational and we should let the community make a consensus choice from amongst them.
> 
> I see now that my real objection is to CBOR being initially standards track. What we should do is to begin with Informational descriptions for existing standards that are widely used (MongoDB's BSON for example) and Experimental proposals for anything new. Then we should see if there is the possibility of convergence on one of the proposals.
> 
> 
> I dropped a note into the BSON mailing list to see what their response might be but with no reply so far.
> 
> 
> -- 
> Website: http://hallambaker.com/