On Aug 10, 2013, at 12:25 PM, Ted Lemon <Ted.Lemon@xxxxxxxxxxx> wrote: > On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> wrote: >> That's fair, and I should have been clearer. I think 'Informatonal' is more appropriate for now, because I don't think we know what the "it" is in your above statements - i.e., I don't know what Internet use-cases and/or IETF protocols CBOR was intended to be used for. For example, is the purpose of it to be JSONv2 for Javascript uses, vs. a new encoding for DNS AXFR/IXFR, vs. an encoding for a NoSQL inter-DB synch protocol, vs. a new encoding for MIME bodies in SMTP. I don't see how we can know whether an encoding mechanism is sound or broken without knowing what its intended/motivating use-case is. > > Section 1.1 goes on at some length about the intended use for the document is. If you believe it is unclear or incomplete, some pointed questions about it would be entirely appropriate. OK... I read that section previously, and I just re-read it now, and I think that section is quite clear on the *design* goals. And I think it meets those goals. That's why I said, if that's all that's needed for PS, then I'm cool. I literally don't know whether or not a PS for an encoding mechanism needs any more than that - I deal mostly with protocol docs, not encoding docs. And I don't know whether the same considerations make sense or not for an encoding doc. I'm quite sensitive to not blocking people from progress, as I've been in similar situations myself. So I'm just giving my 2 cents, because I happen to have looked at it for using it as a binary JSON alternative for a non-IETF application. What I'm curious about is the intended IETF protocol use-case(s). I don't think a use-case even needs to be stated in the doc, because this doc is really about a generic object encoding mechanism; it has properties X, and if you want properties X then you should use it. I'm more just asking what the authors were targeting, if anything. For example, if it's intended for a new encoding mechanism for IPFIX I'd have strong opinions one way; whereas if it's a new encoding mechanism for DNS zone transfers I'd probably have a different opinion. But if the use-case is just "anything that needs our properties X", that's fine too. >From reading the doc, it feels like it's intended to be the successor for MessagePack. Afaik, MessagePack is used by a broad community as a drop-in replacement for JSON. (I could be wrong on that, it's just my impression and how I plan to use it) If that's the goal of CBOR, then I think it will have a tough time of it but I've got no objection to letting it try. >> I read RFC 1958 yesterday when I saw your previous email, and I read it again this morning when I saw your comment above. But I still don't grok which part of it let's me tell a WG Chair: "No, just because there's a PS RFC doing something similar, doesn't mean we can't do something better and more appropriate for this particular application". I mean I can tell them that now, but it doesn't carry much weight. What part of RFC 1958 would help me making such a statement? > > Section 3. If you only read section 3.2, and don't read the last clause of the last sentence in that section, then you might come to the conclusion that once an RFC is published that solves a specific problem, no other RFC can ever be published that addresses a similar problem. > Section 3.2 definitely does argue that if you have a good solution to a problem, you shouldn't invent a new solution to the problem. If you were to apply section 3.2 strictly without all the caveats, you could argue that this document shouldn't be published because ASN.1 solves the same problem. But that's not a correct reading of the document, because of all the other caveats that are listed in subsequent sections. Ahh, I see. I did read that sentence but it felt more like an afterthought escape clause. :) That's good to know though. -hadriel