On Aug 10, 2013, at 10:21 AM, Ted Lemon <Ted.Lemon@xxxxxxxxxxx> 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