On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan <hadriel.kaplan@xxxxxxxxxx> wrote: > 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. Fair point. RFC2026 does not in fact make the distinction I made. Here is what RFC 2026 says about proposed standards: A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Here is what it says about Informational documents: An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). In practice, the qualifications for Informational generally don't give us any reasonable expectation of interoperability, nor do they require it. There is one exception: Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. As a practice, we also do sometimes publish informational documents that were produced by working groups and that were intended to be standards, but that were not selected by the working group to be standards, but that nevertheless are considered to be useful to the community for informational purposes. But the most common examples of informational documents are operational practices documents that do not qualify as BCP, reports, architecture documents, requirements documents, gap analyses and other analyses. It is on this basis that I made the claim that informational documents generally aren't intended to interoperate. > 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. > 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." I can't speak for the IESG. You already know what my opinion as an individual AD is—I am not strongly in favor of publishing this document, because it's out of my area, but I haven't seen any argument raised against publishing it that I find convincing; in particular I do think it's appropriate to publish it as a standards-track document if it's found to have consensus. > 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.