ietf
[Top] [All Lists]

Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-10 15:57:33

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


<Prev in Thread] Current Thread [Next in Thread>