On Aug 10, 2013, at 12:25 PM, Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan
<hadriel(_dot_)kaplan(_at_)oracle(_dot_)com> 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