On Aug 10, 2013, at 10:21 AM, Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
The reason we call things "proposed standard" is because we expect
interoperability. A thing that can't have or affect interoperability
probably isn't a "proposed standard." In this case, what we have is
definitely a proposed standard and not an informational document; the
question is whether it's a standard that will get IETF consensus.
I'm not sure if you intended to, but you're implying non-standards-track docs
are only for things we don't expect interoperability for, or cannot have or
affect interoperability. I've read RFC 2026, and afaict non-standards-track
docs can still be things that have or affect interoperability. That's not to
say it ought not to be PS, obviously, but more that a statement of "what we
have is definitely a proposed standard" seems like jumping the gun to me.
I should point out that a lot of arguments have been raised here that don't
really affect consensus. The arguments to raise if you think a proposed
standard is a bad idea are technical arguments: "this won't work because of
X" or architectural arguments: "we shouldn't do this because there is a
better way to do it that fits better with the Internet architecture" or "this
is needlessly complicated for the use case we are trying to address."
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.
But, if the IESG feels an encoding mechanism doesn't need any targeted use-case
to be published as a PS, then please ignore my email for purposes of consensus.
I'm not strongly for/against - just answering Barry's original question, from
the peanut gallery as I said in my original email. And as I said in my
original email: "[the draft] doesn't appear to contain technical errors nor
fail to meet its self-stated design objectives."
Importantly, "we shouldn't do this because there's a proposed standard that
does something similar" is _not_ a valid argument; if the proposed standard
is technically or architecturally better, _that_ is the argument to raise.
The mere existence of the RFC is not an argument in itself.
Seriously, RFC 1958 is a good document to read if you are interested in this
issue. You might also want to read RFC 5218.
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?
-hadriel