Thank you for your review! It was certainly different from most Gen-ART reviews, but has generated interesting discussion. I believe other ADs at the IESG have raised the issue whether this should be the standard way to do things, or just a way. Lets see where the discussion ends.
Jari On Jul 30, 2013, at 10:05 AM, Martin Thomson <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-bormann-cbor-04 > Reviewer: Martin Thomson > Review Date: 2013-07-29 > IETF LC End Date: ? > IESG Telechat date: 2013-08-15 > > Summary: > This document is not ready for publication as proposed standard. > > I'm glad that I held this review until Paul's appsarea presentation. > This made it very clear to me that the types of concerns I have are > considered basically irrelevant by the authors because they aren't > interested in changing the design goals. I don't find the specific > design goals to be interesting and am of the opinion that the goals > are significant as a matter of general application. I hope that is > clear from my review. > > Independent of any conclusions regarding design goals, there are > issues that need addressing. > > (This is an atypical Gen-ART review. I make no apologies for that. I > didn't intend to write a review like this when I started, but feel > that it's important to commit these thoughts to the record. It's also > somewhat long, sorry. I tried to edit it down.) > > I have reviewed the mailing list feedback, and it's not clear to me > that there is consensus to publish this. It might be that the dissent > that I have observed is not significant in Barry's learned judgment, > or that this is merely dissent on design goals and therefore > irrelevant. The fact that this work isn't a product of a working > group still concerns me. I'm actually interested in why this is > AD-sponsored rather than a working group product. > > Major issues: > My major concerns with this document might be viewed as disagreements > with particular design choices. And, I consider it likely that the > authors will conclude that the document is still worth publishing as > is, or perhaps with some minor changes. In the end, I have no issue > with that, but expect that the end result will be that the resulting > RFC is ignored. > > What would cause this to be tragic, is if publication of this were > used to prevent other work in this area from subsequently being > published. (For those drawing less-than-charitable inferences from > this, I have no desire to throw my hat into this particular ring, > except perhaps in jest [1].) > > This design is far too complex and large. Regardless of how > well-considered it might be, or how well this meets the stated design > goals, I can't see anything but failure in this document's future. > JSON succeeds largely because it doesn't attempt to address so many > needs at once, but I could even make a case for why JSON contains too > many features. > > In comparison with JSON, this document does one major thing wrong: it > has more options than JSON in several dimensions. There are more > types, there are several more dimensions for extensibility than JSON: > types extensions, values extensions (values of 28-30 in the lower bits > of the type byte), plus the ability to apply arbitrary tags to any > value. I believe all of these to be major problems that will cause > them to be ignored, poorly implemented, and therefore useless. > > In part, this complexity produces implementations that are far more > complex than they might need to be, unless additional standardization > is undertaken. That idea is something I'm uncomfortable with. > > Design issue: extensibility: > This document avoids discussion of issues regarding schema-less > document formats that I believe to be fundamental. These issues are > critical when considering the creation of a new interchange format. > By choosing this specific design it makes a number of trade-offs that > in my opinion are ill-chosen. This may be in part because the > document is unclear about how applications intend to use the documents > it describes. > > You may conclude after reading this review that this is simply because > the document does not explain the rationale for selecting the approach > it takes. I hope that isn't the conclusion you reach, but appreciate > the reasons why you might do so. > > I believe the fundamental problem to be one that arises from a > misunderstanding about what it means to have no schema. Aside from > formats that require detailed contextual knowledge to interpret, there > are several steps toward the impossible, platonic ideal of a perfectly > self-describing format. It's impossible because ultimately the entity > that consumes the data is required at some level to understand the > semantics that are being conveyed. In practice, no generic format can > effectively self-describe to the level of semantics. > > This draft describes a format that is more capable at self-description > than JSON. I believe that to not just be unnecessary, but > counterproductive. At best, it might provide implementations with a > way to avoid an occasional extra line of code for type conversion. > > Extensibility as it relates to types: > The use of extensive typing in CBOR implies an assumption of a major > role for generic processing. XML schema and XQuery demonstrate that > this desire is not new, but they also demonstrate the folly of > pursuing those goals. > > JSON relies on a single mechanism for extensibility. JSON maps that > contain unknown or unsupported keys are (usually) ignored. This > allows new values to be added to documents without destroying the > ability of an old processor to extract the values that it supports. > The limited type information JSON carries leaks out, but it's unclear > what value this has to a generic processor. All of the generic uses > I've seen merely carry that type information, no specific use is made > of the knowledge it provides. > > ASN.1 extensibility, as encoded in PER, leads to no type information > leaking. Unsupported extensions are skipped based on a length field. > > (As an aside, PER is omitted from the analysis in the appendix, which > I note from the mailing lists is due to its dependency on schema. > Interestingly, I believe it to be possible - though not trivial - to > create an ASN.1 description with all the properties described in CBOR > that would have roughly equivalent, if not fully equivalent, > properties to CBOR when serialized.) > > By defining an extensibility scheme for types, CBOR effectively > acknowledges that a generic processor doesn't need type information > (just delineation information), but it then creates an extensive type > system. That seems wasteful. > > Design issue: types: > The addition of the ability to carry uninterpreted binary data is a > valuable and important feature. If that was all this document did, > then that might have been enough. But instead it adds numerous > different types. > > I can understand why multiple integer encoding sizes are desirable, > and maybe even floating point representations, but this describes > bignums in both base 2 and 10, embedded CBOR documents in three forms, > URIs, base64 encoded strings, regexes, MIME bodies, date and times in > two different forms, and potentially more. > > I also challenge the assertion made where the code required for > parsing a data type produces larger code sizes if performed outside of > a common shared library. That's arguably provably true, but last time > I checked a few extra procedure calls (or equivalent) weren't the > issue for code size. Sheer number of options on the other hand might > be. > > Half-precision floating point numbers are a good example of excessive > exuberance. They are not available in many languages for good reason: > they aren't good for much. They actually tend to cause errors in > software in the same way that threading libraries do: it's not that > it's hard to use them, it's that it's harder than people think. And > requiring that implementations parse these creates unnecessary > complexity. I do not believe that for the very small subset of cases > where half precision is actually useful, the cost of transmitting the > extra 2 bytes of a single-precision number is not going to be a > burden. However, the cost of carrying the code required to decode > them is not as trivial as this makes out. The fact that this requires > an appendix would seem to indicate that this is special enough that > inclusion should have been very carefully considered. To be honest, > if it were my choice, I would have excluded single-precision floating > point numbers as well, they too create more trouble than they are > worth. > > Design issue: optionality > CBOR embraces the idea that support for types is optional. Given the > extensive nature of the type system, it's almost certain that > implementations will choose to avoid implementation of some subset of > the types. The document makes no statements about what types are > mandatory for implementations, so I'm not sure how it is possible to > provide interoperable implementations. > > If published in its current form, I predict that only a small subset > of types will be implemented and become interoperable. > > Design issue: tagging > The tagging feature has a wonderful property: the ability to create > emergency complexity. Given that a tag itself can be arbitrarily > complex, I'm almost certain that this is a feature you do not want. > > Minor issues: > Design issue: negative numbers > Obviously, the authors will be well-prepared for arguments that > describe as silly the separation of integer types into distinct > positive and negative types. But it's true, this is a strange choice, > and a very strange design. > > The fact that this format is capable of describing 64-bit negative > numbers creates a problem for implementations that I'm surprised > hasn't been raised already. In most languages I use, there is no > native type that is capable of carrying the most negative value that > can be expressed in this format. -2^64 is twice as large as a 64-bit > twos-complement integer can store. > > It almost looks as though CBOR is defining a 65-bit, 33-bit or 17-bit > twos complement integer format, with the most significant bit isolated > from the others, except that the negative expression doesn't even have > the good sense to be properly sortable. Given that and the fact that > bignums are also defined, I find this choice to be baffling. > > Document issue: Canonicalization > Please remove Section 3.6. c14n is hard, and this format actually > makes it impossible to standardize a c14n scheme, that says a lot > about it. In comparison, JSON is almost trivial to canonicalize. > > If the intent of this section is to describe some of the possible > gotchas, such as those described in the last paragraph, then that > would be good. Changing the focus to "Canonicalization > Considerations" might help. > > I believe that there are several issues that this section would still > need to consider. For instance, the use of the types that contain > additional JSON encoding hints carry additional semantics that might > not be significant to the application protocol. > > Extension based on minor values 28-30 (the "additional information" space): > ...is impossible as defined. Section 5.1 seems to imply otherwise. > I'm not sure how that would ever happen without breaking existing > parsers. Section 5.2 actually makes this worse by making a > wishy-washy commitment to size for 28 and 29, but no commitment at all > for 30. > > Nits: > Section 3.7 uses the terms "well-formed" and "valid" in a sense that I > believe to be consistent with their use in XML and XML Schema. I > found the definition of "valid" to be a little difficult to parse; > specifically, it's not clear whether invalid is the logical inverse of > valid. > > Appendix B/Table 4 has a TBD on it. Can this be checked? > > Table 4 keeps getting forward references, but it's hidden in an > appendix. I found that frustrating as a reader because the forward > references imply that there is something important there. And that > implication was completely right, this needs promotion. I know why > it's hidden, but that reason just supports my earlier theses. > > Section 5.1 says "An IANA registry is appropriate here.". Why not > reference Section 7.1? > > [1] https://github.com/martinthomson/aweson > _______________________________________________ > apps-discuss mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
