On Wed, Feb 19, 2014 at 4:48 PM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
Hi Barry,Selective quoting:
At 13:10 19-02-2014, Barry Leiba wrote:
Phill took the first step of addressing his complaint to the
responsible AD (me). This is my response. If he or someone else
should choose to pursue a further appeal, the next step would be to
take it to the IESG by way of the Chair.
RFC 7049 was published in October 2013. As Sam Hartman mentioned it was a decision of the IESG.
"During the November IETF meeting, I received an appeal from Phillip
Hallam-Baker to the publication of CBOR, RFC 7049, on the Standards
Track."
That falls under the IESG.
"Phill is questioning the process;"
The handling of the appeal is odd.
The whole process has been odd.
I told Jari and Barry that I was appealing the decision in Vancouver. I was told to raise it with the relevant AD first. By the time he had come to a decision it was that too much effort had gone into building things on top of CBOR since to undo the original decision.
I now realize that what I should have done was to simply send the original appeal to the IETF list and not gone through channels as requested.
The fundamental problem here is that as I see it the protocol world is rapidly converging on JSON as the encoding of choice and there are many good reasons why it is a better encoding than any of the text based alternatives on offer (RFC822, XML). It is thus inevitable that people will ask if a binary encoding of JSON would be better than ASN.1. Which of course is true and not just because hitting yourself on the foot repeatedly with a hammer is better than ASN.1.
JSON is good for a lot of things, but not for passing encrypted objects around unless they are really small. So JOSE is interesting but only in a very limited field. If we can encode binary data in JSON without a 33% inflation in size, JOSE suddenly becomes very interesting indeed.
If JOSE didn't inflate the size of a data object, we could use it for data level encryption. Drop a content type tag and some other metadata on the wrapper, encrypt the contents and we can have a CMS like blob that fits the Internet idiom much better (and there is some soon to expire IP that would make animating that proposal very interesting).
But now we have a binary encoding published on IETF standards track that is not a binary encoding of JSON but has a subset that could be used to encode JSON sitting in that spot. It isn't a consensus document, isn't a product of open process, it is however on IETF standards track. So the job for anyone doing the job properly has become harder.
So it is kind of like the Sochi which will always be the OoOo* Olympics.
The only thing that makes an encoding interesting is that a constituency of users agree to all make use of it. JSON has emerged from a field of thousands of text encodings because it is the best compromise between simplicity and functionality that has such a wide user base. So having random specs given standards status when the designers only attempted to solve the problems they cared about does not help matters.
My main concern is the process question. I really don't care whether CBOR is a PROPOSED STANDARD or whatever. What I do care about is if I am told that I have to use it because that is the IETF standard for binary encoding. And what I care most about is the risk that this approach of 'its our ball and only we will decide who gets to play' is going to be repeated.
There are cases where it makes perfect sense for a draft to go straight onto the standards track. There are plenty of extensions to PKIX that are important enough to write down but not so important that it is worth running up a whole working group just to decide them.
But a spec whose only purpose is to provide a platform for other specs really needs to clear a higher bar than not being idiotic and having some people willing to implement. There have to be people who want to choose to build on it.
The way I think the process should work is:
1) The IAB identifies the need for a consensus binary encoding for JSON as a platform the IETF community can build on (or why call it an architecture board).
2) People write drafts that elaborate on the requirements and/or propose schemes that meet them, these are published as either EXPERIMENTAL or INFORMATIONAL.
3) People who are building applications that build on the platform kick the tires and decide which ones they like / hate etc. Either a consensus emerges that one encoding is best in which case we can go to step 4, otherwise we go back to step 2.
4) PROPOSED STANDARD status is awarded in recognition of the fact that there is a defacto standard that application protocol designers have converged on. This may involve spinning up a working group to clean up the documents or not depending on their quality.
I have seen the shotgun standards approach in the past. BEEP tried that route, it was a complete failure as a result because it moved through the standards process so fast it never gained any buy in outside the original design team. So even though it has features that are very sound and the HTTP/2.0 WG might well end up re-inventing it was still born because the proposers thought that standards track was the route to driving adoption rather than recognition of adoption.
Standards is the process of making decisions that don't matter. It does not really matter what the HTTP protocol syntax is provided that a decision has been made to choose one syntax for that task instead of five.
So I would like to see the IAB actually doing the job of an architecture board and identifying gaps in the IETF stack where convergence on one particular way of solving a problem would be beneficial. That is not saying that they should be the people providing the solution.
Website: http://hallambaker.com/