Appeal from Phillip Hallam-Baker on the publication of RFC 7049 on the Standards Track
Barry Leiba <barryleiba@computer.org> Tue, 18 February 2014 22:49 UTC
Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2D1A04E5 for <ietf@ietfa.amsl.com>; Tue, 18 Feb 2014 14:49:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MFGaRTpalx5 for <ietf@ietfa.amsl.com>; Tue, 18 Feb 2014 14:49:41 -0800 (PST)
Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7435A1A0268 for <ietf@ietf.org>; Tue, 18 Feb 2014 14:49:41 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id k4so24482207qaq.15 for <ietf@ietf.org>; Tue, 18 Feb 2014 14:49:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=0+lVsjPrAiPQqyHKdb6GTPuoxGFsOwSlyc78LfAJx1k=; b=DQfciTxkPBaaUU6tZTRnWlCov/ufO66oHtMubhRhMPMNNUcfRZHSzealil1laq33kW V5Q14s405TpYhLj7PxGTubfRylw90IMEncn5lzVeBVxr4K4X+TzrdII+GlSZn4R8ynWK V2D8wRmQENN1oSvls/AH7rwcBUtKV+WwNzH78T+WQpsGcMVr6drDqdccqocgvjsLUf8C /UO9Fk5viUbmxPl6aT8WIzHCFGMC6+TVItw/gWzFhMBWxIFILxI0CiI+SjtPhrz6wYYC lyOxN3ARaKD9cWz3lU72jY8LoqrlJpbbFMwH69Yl7kUWcepdPKhJjbeMdaS10ENcLMJ8 7fqQ==
MIME-Version: 1.0
X-Received: by 10.140.30.230 with SMTP id d93mr44511710qgd.51.1392763777992; Tue, 18 Feb 2014 14:49:37 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.224.26.11 with HTTP; Tue, 18 Feb 2014 14:49:37 -0800 (PST)
Date: Tue, 18 Feb 2014 17:49:37 -0500
X-Google-Sender-Auth: -sedV9ZK50uutWaCLvA9sFnNAig
Message-ID: <CALaySJK8xBz6DeYNVv-Q5ctbSkoqOfZ9ZK-wKdtp3JvfmDbseg@mail.gmail.com>
Subject: Appeal from Phillip Hallam-Baker on the publication of RFC 7049 on the Standards Track
From: Barry Leiba <barryleiba@computer.org>
To: IETF discussion list <ietf@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/uv8DNQOeW4_m77MQAnuqbUT9I0g
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 22:49:43 -0000
During the November IETF meeting, I received an appeal from Phillip Hallam-Baker to the publication of CBOR, RFC 7049, on the Standards Track. (Procedural note: The appeal was, at this point, to me as the responsible AD, and has not gone to the IESG.) Phill is questioning the process; specifically, Phill's appeal is as follows: -------------------------- start -------------------------- My issue here is more than a preference for one encoding over another, the manner in which CBOR was made a standard has negated the value of having it being proposed as a standard. There are already five JSON in binary encodings in widespread use. CBOR offers no particular advantages over any of the existing schemes and the authors have never been willing to explain why a different encoding is desirable. An IETF standard would have had the advantage of being a single choice that people could use but only if it was capable of meeting all the requirements that might be raised and only if it was genuinely supported by IETF consensus. Using the individual submission process to shortcut the process suggests that you don't consider the technical differences between encodings very important. An encoding is a foundational piece f work that requires an open process because other people are going to be building on it. - CBOR is more complex than JSON and introduces a different data model. It reintroduces features such as definite/indefinite length encodings that have already been found to be defective in ASN.1. - CBOR is an alternative to JSON encoding and not as many people supported on the APPs list, a simple extension that adds in the functionality of length delimited strings and binary blobs. - CBOR does not support compression of tags or strings and there is no way in which it can be extended to support this capability. It can however be extended to support new intrinsic types such as a new type of integer or float. Which is precisely the type of extensibility JSON rejects. Had there been an open process, those of us who had requirements and code that depended on the requirements could have raised them and there would have been a possibility of a single output from the work. Instead CBOR does nothing to address the problem of multiple encoding options and only adds another option on the table. --------------------------- end --------------------------- I've taken an unusually long time to resolve this, and for that delay I apologize and appreciate Phill's patience on -- his appeal did come in within the two-month appeal window after the approval announcement. As I evaluated the appeal, I reviewed every message in the discussion threads. In the end, my conclusion is that I support the appeal. I think that Phill is right that we should have had open discussion of the design criteria before considering a specific proposal for an encoding. The result of not having done that was that we approved an encoding scheme that meets certain use cases and design goals, without having first discussed what use cases and design goals the community might want to have covered. I think it's important for ADs to consider, when deciding to sponsor non-working-group documents, whether a broader design discussion is appropriate. I believe that I made a mistake in not considering that for this case. As to a remedy, I do not see that changing the status of RFC 7049 -- for example, moving it from Standards Track to Experimental -- would be in the best interest of the IETF at this point. CBOR had a good deal of interest when it was proposed, and that interest has continued and is resulting in implementations (see http://cbor.io/impls.html for one list of what's going on with respect to CBOR implementations). A change to RFC 7049 now would not likely change anything, and would result in time wasted in moving it back to Standards Track at a suitable time. I thank Phill for persisting in pointing out what I missed, and I intend to consider this more strongly in future decisions about sponsoring potential standards. Barry, Applications AD
- Appeal from Phillip Hallam-Baker on the publicati… Barry Leiba
- Re: Appeal from Phillip Hallam-Baker on the publi… Phillip Hallam-Baker
- Re: Appeal from Phillip Hallam-Baker on the publi… Joe Hildebrand
- Re: Appeal from Phillip Hallam-Baker on the publi… Barry Leiba
- Re: Appeal from Phillip Hallam-Baker on the publi… John C Klensin
- Re: Appeal from Phillip Hallam-Baker on the publi… Barry Leiba
- Re: Appeal from Phillip Hallam-Baker on the publi… Barry Leiba
- Re: Appeal from Phillip Hallam-Baker on the publi… S Moonesamy
- Re: Appeal from Phillip Hallam-Baker on the publi… Phillip Hallam-Baker
- Re: Appeal from Phillip Hallam-Baker on the publi… Tim Bray
- RE: Appeal from Phillip Hallam-Baker on the publi… l.wood
- Re: Appeal from Phillip Hallam-Baker on the publi… Dave Crocker
- Re: Appeal from Phillip Hallam-Baker on the publi… Mark Nottingham
- Re: Appeal from Phillip Hallam-Baker on the publi… S Moonesamy
- Re: Appeal from Phillip Hallam-Baker on the publi… Eliot Lear
- Re: Appeal from Phillip Hallam-Baker on the publi… Ralph Droms
- Re: Appeal from Phillip Hallam-Baker on the publi… Phillip Hallam-Baker
- Re: Appeal from Phillip Hallam-Baker on the publi… Phillip Hallam-Baker
- Re: Appeal from Phillip Hallam-Baker on the publi… Sam Hartman
- Re: Appeal from Phillip Hallam-Baker on the publi… Barry Leiba
- Re: Appeal from Phillip Hallam-Baker on the publi… S Moonesamy
- Re: Appeal from Phillip Hallam-Baker on the publi… Phillip Hallam-Baker
- Re: Appeal from Phillip Hallam-Baker on the publi… S Moonesamy