On Aug 10, 2013, at 11:30 AM, Hadriel Kaplan
<hadriel(_dot_)kaplan(_at_)oracle(_dot_)com> 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.