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

From: Joe Hildebrand <[email-masked]>
Date: Tue, 06 Aug 2013 09:41:23 -0600

On 7/29/13 4:54 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>There are existing specs that does what CBOR does just as well that have
>actual users.

Some of these were approached, and none of them thought that having a
standard for their format was worth the amount of heartache that dealing
with the IETF would entail.  If you can get one of those communities
interested, that would be cool.

> There are requirements that the individuals proposing this chose not to
>address.

Re-enumerating those for this discussion might be useful.

-- 
Joe Hildebrand

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 6 Aug 2013 13:34:21 -0400

> Re-enumerating those for this discussion might be useful.

The issue here is whether this proposal should be an IETF Proposed STANDARD.

I think that is nuts and I would think it just as much nuts if it was my
proposal. We have no real world implementation experience by which I mean
using it in a protocol and not writing some python

Usually when the IETF publishes an algorithm it is given INFORMATIONAL or
EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627
has INFORMATIONAL status despite the fact that at the time it was written
there was a lot of implementation.

Using the individual submissions track as a way to circumvent working group
process when there is an actual IETF JSON working group seems completely
wrong to me.

For the record, the issues I see are:

1) This is an entirely new encoding and semantics. It is not JSON in binary
which is what we actually need.

2) No support for tag compression.

3) No support for decimal floating point.

4) Its all or nothing, no layering.

The first one is my main complaint. I want to be able to use the binary and
text JSON encodings interchangeably and not have the upper layers to have
to bother with it at all.

That is why I designed a system where a single reader can read binary and
text without the need for any additional state (beyond tracking how the
current item is encoded.)

What I like in JSON is the lack of features and the fact that JSON covers
95% of all my needs as is. All I want to add in to get to 100% features are
the ability to encode floating point without loss and the ability to
efficiently encode binary blobs.

-- 
Website: http://hallambaker.com/

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 06 Aug 2013 12:18:41 -0600

>The issue here is whether this proposal should be an IETF Proposed

standards-track != standard, right?

>using it in a protocol and not writing some python

When I parse your words closely, I see you calling the idea "nuts", but
the emotional reaction I had was that you had called *me* "nuts".
Regardless, this seems a little out of proportion to what I thought was a
relatively polite attempt at dialog.  I'm worried that this kind of
interaction is exactly the sort of thing that scares new communities away
from participating here.

>there was a lot of implementation.

I would argue that if 4627 had received the more-thorough review that
would have come from being on standards track, it might not have had as
many problems as we're finding that it does.

>Using the individual submissions track as a way to circumvent working
>group process when there is an actual IETF JSON working group seems
>completely wrong to me.

First, this isn't JSON, even though interop with JSON was a goal.

Second, if the JSON wg wanted to recharter with a broader mission that
included CBOR and other similar protocols, that might be interesting to
me.  I don't get the sense from what I've seen in that group that there
would be enough energy for that, but that is obviously not for me to
decide.

Third, I think I said in my long message that I wouldn't mind having a
working group look at this, so I'm not sure why you'd accuse me of
circumventing process here.

>1) This is an entirely new encoding and semantics. It is not JSON in
>binary which is what we actually need.

To me, it appears to be a proper superset of the parts of JSON that are
safe to use.

>2) No support for tag compression.

That's an interesting requirement, and one that I think could be added to
the design if there were others that felt motivated to help.  I think I
can see a way that it could be added later: create a new tag that precedes
a map of string-to-int conversions.

However, my intuition is that this wouldn't have radically better behavior
than gzip, and so I'd like to see some numbers to prove that the
complexity was worthwhile.

>3) No support for decimal floating point.

Section 2.4.3 describes decimal fractions.  Can you describe what other
behavior you'd like?  Or are you arguing that you'd like to see that moved
to being a core type?

>4) Its all or nothing, no layering.

Could you say more about that?  I see the tagging system as being exactly
a layering system, where you are explicitly invited to ignore any tag you
don't implement.

>The first one is my main complaint. I want to be able to use the binary
>and text JSON encodings interchangeably and not have the upper layers to
>have to bother with it at all.

I think I understand this.  I could see where my CBOR event-based parser
could also take JSON in, and generate the exact same events.  I might even
do that as a proof of concept.  Could you say more about what in CBOR you
think violates this?

Understandably, some type information will be lost converting
CBOR-to-JSON, but that will be true for anything that we come up with in
this space, I think.

>95% of all my needs as is. All I want to add in to get to 100% features
>are the ability to encode floating point without loss and the ability to

I'd add dates to this, but I mostly agree with you.  CBOR, to me, was
close enough to what I wanted, explained in a way that made it easy to
implement, and I could ignore the bits that I didn't need for my use
cases.  I got over the fact that it was different than what I had
originally wanted, that it has some complexifying features like streaming
(added at the request of the community), and that we couldn't get any of
the existing players in the space to bring their work to us.

-- 
Joe Hildebrand

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Aug 2013 21:11:23 +0200

>> 2) No support for tag compression.

(I assume this was about map keys, not about tags.)

> a map of string-to-int conversions.

I'd probably do it the other way around:

	tagN([{1: "foo", 2: "bar"}, ...abbreviated data item...])
Where an abbreviated data item of the form
	[1, 2, 3, {1: "beer", 2: "wine", "baz": 1}, 5, 6]
would then be interpreted as
	[1, 2, 3, {"foo": "beer", "bar": "wine", "baz": 1}, 5, 6]

Yes, processing of this kind is easy to add as a tag.
If the first parameter is instead a URI (preferably ni: scheme), it could save carrying around a large dictionary.

> complexity was worthwhile.

I share that intuition.  CBOR is intended to be useful also in those environments where running a full compression algorithm is impractical; here such a scheme could still have benefits.

>> have to bother with it at all.

(The applications I have in mind use media types, but:)

> do that as a proof of concept.  Could you say more about what in CBOR you

Well, if you don't have a media type, and don't know whether you'll get a JSON text or a CBOR data item, you may need to mechanically distinguish them.
E.g., the following six characters can occur at the start of a JSON text.
All are valid as start (or only) byte of a CBOR data item:

Byte    JSON meaning                CBOR interpretation

%x20  ; Space                       -1
%x09  ; Horizontal tab              9
%x0A  ; Line feed or New line       10
%x0D  ; Carriage return             13
%x5B  ; [ left square bracket       starts byte string
%x7B  ; { left curly bracket        starts UTF-8 string

(Well, for any valid JSON texts, heuristics might tell you the string data items a CBOR parser sees are unrealistically large.)

If a CBOR application does require initial signature bytes for self-description purposes, I would suggest using something like

	0xd8 0xf8 ...data item...

which decodes as tag248(data item); we could define 248 as a no-op tag.

(I'm still working on your other message -- lots of juicy input, thank you!)

Grüße, Carsten

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 06 Aug 2013 13:45:46 -0600

On 8/6/13 1:11 PM, "Carsten Bormann" <[email-masked]> wrote:

>If a CBOR application does require initial signature bytes for
>self-description purposes, I would suggest using something like
>

Or a no-op simple value; we could easily pick one that did not generate a
valid first character for JSON.

-- 
Joe Hildebrand

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Aug 2013 10:03:55 +0200

> The issue here is whether this proposal should be an IETF Proposed STANDARD.
...
> there was a lot of implementation.

First, Proposed Standard is just that: a proposal.  It does not
require implementations.  It requires that it be "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."  That's from RFC 2026,
Section 4.1.1, which goes on to say, "Usually, neither implementation
nor operational experience is required for the designation of a
specification as a Proposed Standard."

I believe that CBOR qualifies, which is why I agreed to AD-sponsor it.
 In the process, I'm looking to see if we have rough consensus that
all this is the case.  Your substantive comments on the document, as
well as those of others, should address those points (as some of your
comments indeed do).

Second, RFC 4627 is Informational because it was not meant to be the
standard definition of JSON.  It was meant only to register the media
type.  But one thing led to another, and it did become the referenced
definition, which is why the JSON working group is working on fixing
its gaps and moving it to Standards Track.

> process when there is an actual IETF JSON working group seems completely

No one is circumventing anything.  The JSON working group is not
chartered to deal with this or other documents like it, and we won't
be rechartering it to do so any time soon.  And remember that any time
I'm sponsoring a document as AD, part of what I'm doing is what
working group chairs do in a working group: judging rough consensus on
the document's content and the issues that concern whether it's
intended status is appropriate.  If you (and/or others) can show that
there are solid reasons that this should not be a Proposed Standard,
or if I do not see rough consensus to publish it, I will not bring it
to the rest of the IESG.

Barry, Applications AD

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 7 Aug 2013 10:24:37 +0200

> valid first character for JSON.

Well, simple values don't have "content".
Using one as a signature would mean the data item ends right on the simple value, and the actual payload would be a second data item.  I'd rather have a single data item that is just (ignorably) tagged.

Yes, picking a tag number that encodes into a file signature that can't be a valid start for JSON (or many other kinds of things, e.g. UTF-8 text) is easy, as demonstrated above.

Grüße, Carsten

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Aug 2013 01:28:29 -0700

On Wed, Aug 7, 2013 at 1:03 AM, Barry Leiba <[email-masked]> wrote:

> group
I would add that CBOR has already seen enough interest and feedback that I
believe it would pass a call for adoption in APPSAWG, and be processed
there onto the standards track.  That would make Barry's job quite a bit
easier, since it would then be our job to host the discussion and record
consensus in that context.  It would also get a shorter IETF Last Call.

Instead, it's going what is for all intents and purposes a tougher route.
I'm not suggesting we derail its progress to do it the other way, but it
does suggest to me that the route it's following is hardly a shortcut or
bypass of some kind.

-MSK

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Aug 2013 10:47:15 -0400

The point is that there would BE discussion. Consensus is not enough, the
process has to be open. A consensus formed by keeping people out of the
room is no consensus at all.

Though if the discussion was of the form 'this was already decided' then
that effort would be a farce as well.

What we need for 90% of IETF specifications is nothing more than an easy
way to extend JSON to encode binary blobs without BASE64 encoding. Just
that, nothing more. Instead we have a reinvention of ASN.1 without a schema.

When I say nothing more, I don't mean the rest would be 'nice to have' or
harmless, I mean that it is positively harmful.

I want to be able to mix binary and text forms of the JSON encoding in the
same object. For example, we have part A that collects JSON datagrams from
B and C and puts a wrapper round them. This is a very common requirement in
a network protocol (and one of the things that XML was meant to do but is
horrible at). If we can mix and match Text/Binary JSON this is very simple,
the packager can just include the input from B and C into its output stream
as opaque blobs without having to decide whether to convert them to make
the inner format compatible with the outer wrapper or each other.

The way that we normally decide issues as important as a data encoding
format is to have an open competition where multiple proposals can be made
by anyone with an idea. That is how W3C managed the binary encoding of XML
and how the HTTP 2.0 compression issue is being addressed. The process for
CBOR has been that Carsten writes a spec and then Paul Hoffman acts as Czar
deciding which requirements are to go in it.

At any rate, I have an open source tool on source forge now that generates
an Internet Draft, Examples and sample code from a simple abstract schema.
It currently uses JSON coding but I will be adding a binary encoding, hence
my interest.

I would be happy to add an IETF Proposed Standard binary encoding that had
been the result of an open process.

On Wed, Aug 7, 2013 at 4:28 AM, Murray S. Kucherawy <[email-masked]>wrote:

> On Wed, Aug 7, 2013 at 1:03 AM, Barry Leiba <[email-masked]>wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Aug 2013 14:52:06 -0400

Barry,

Could you please answer the questions I put to you privately:

* Will CBOR become the default binary JSON encoding?
* Will other IETF WGs be expected to adopt CBOR as their binary encoding?
* Will you consider publishing alternative binary encodings of JSON?

I accept that there are circumstances where an individual submission is
appropriate. But I do not think that something that is designed to be built
on by other IETF Working Groups is appropriate for individual submission.

Adding a media type or a PKIX feature or HTTP header are all case where
individual submission to Proposed STANDARD is quite appropriate. CBOR is
not.

The test I think should apply here is the dog food test: Is anyone else
going to be expected to eat the product.

In this case we have a specification that I am likely going to have to
argue against as flawed in every WG which might use it. Which is likely to
mean a lot of unnecessary WG effort, IESG effort and appeals.

Most of us here have experience of using ASN.1, XML and JSON. Most of us
have had a considerable amount of unnecessary pain as a result of ASN.1 and
XML. The Web Services world would probably have taken off much quicker if
there has been some debate and discussion before the decision was taken to
turn XML into the standard for data exchange.

Here we have a situation where you have decided to take a short cut on a
decision that could hardly be more fundamental to the design of network
protocols and handed the whole design process off to two individuals to
make a design decision in private.

For example, take the following messages from the CBOR authors:

On Wed, May 22, 2013 at 12:16 PM, Paul Hoffman <[email-masked]>
 wrote:

> On May 22, 2013, at 9:14 AM, Phillip Hallam-Baker <[email-masked]>
> wrote:
>
> > I think we can all agree that *A* binary format would be useful and that
> two dozen are not useful.
>
> Nope, that is patently absurd. That would only be true if everyone agreed
> on all the design goals and decisions for the one binary format, and that
> clearly cannot happen.

I think that one binary format for JSON data structures is an eminently
achievable goal. There is a limited design space, the JSON model covers
almost all necessary data types, the main exception being binary blobs.

At the very most there might be space for one, two or three binary
encodings for use in IETF protocols. But isn't the notion that binary
encodings become like EAP authentication methods and we end up with two
dozen what is really absurd?

On Wed, May 22, 2013 at 6:42 PM, Tony Finch <[email-masked]> wrote:

> Why not BSON or BJSON or UBJSON or MsgPack or ... ?

I never did see that question answered on the list. To be clear, there are
reasons why I don't think the formats Tony suggests cannot become a
universal standard but those objections also apply to CBOR which also has
the problem of not being based on the JSON data model.

The reason that I don't find putting the reasons in the draft an acceptable
substitute to answering the three people who raised the point is that it
was a cop out. Paul and Carsten gave their design rationale unilaterally
and were not prepared to have their decisions challenged.

Neither Paul nor Carsten have ever been noted for ranting about why XML and
ASN.1 are broken. Which I see as a problem because to do a better job than
those two, you really have to understand why those projects went so badly
wrong.

ASN.1 came very close to getting it right but they only did extensibility
as an afterthought and the way they ended up handling it means that you
can't use ASN.1 without a code writing tool which means that you can't use
it from Perl, Python etc. unless someone has written the tool for those.

XML might have been the solution but the XML design team was charged with
writing a document markup language that could be defined using SGML DTD and
data markup only needs about 5% of the features in XML as a result.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Aug 2013 22:19:50 -0700

> room is no consensus at all.

I believe this is why an AD-sponsored document undergoes a Last Call twice
the length of a document that comes out of a working group, and the
comments are typically sent to this list, which is open by definition and
also goes to a more general audience than a working group list would.

I don't see any evidence of attempts to exclude participation here, unless
your concern is sufficiently general that you also believe the Individual
Submission route needs to be abolished because it's too closed.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Aug 2013 20:52:51 +0200

> * Will CBOR become the default binary JSON encoding?

That would be up to the implementors.  If they like it, they will
implement it and use it in other protocols.  No one is suggesting at
this point that there be any specific direction about that -- it's
being proposed as one possible tool.

> * Will other IETF WGs be expected to adopt CBOR as their binary encoding?

Expected by whom?  By me?  No.  By the IESG?  No.  Whom else are you asking?

> * Will you consider publishing alternative binary encodings of JSON?

Again, as you asked *me*, I'll take the "you" in the question as
referring to me.  Of course I will consider that.  My criteria will be
the same as they are for all requests to sponsor documents: I have to
think it's sensible and useful, I have to see reasonable community
support for publishing, and a good level of review that convinces me
that it meets the guidelines for its intended status.  We have to be
able to get something that can meaningfully be called IETF consensus.

> on by other IETF Working Groups is appropriate for individual submission.

We actually do that all the time.  As I said in my other response,
AD-sponsorship is not a fast or easy path for a document, skirting
reasonable process by not giving it to a working group.  For simple
registrations and such, keeping things lightweight makes sense.  But
for something such as this (or DMARC, which I'm also considering
AD-sponsoring), I expect a good deal of support and review -- arguably
*more* than we have had with many working group documents.

CBOR was discussed quite a bit on the apps-discuss list and is now
being discussed on the main IETF list.  It doesn't get more open than
this.  And, I'll repeat what I've said before: there are no "short
cuts" being taken here.

To the rest of the community: Does anyone else think it is not
appropriate to publish CBOR as a Proposed Standard, and see who uses
it?

> In this case we have a specification that I am likely going to have to argue
> against as flawed in every WG which might use it.

Yes, I see your arguments, and I appreciate them.  We need that kind
of input.  I'll let the authors continue to address your comments as
they see they need to.  But I'll also ask the rest of the community...

To the rest of the community: What is your view of Phill's technical
arguments with CBOR?  Do you agree that CBOR is flawed?

Now, as I see it, a main argument you have, Phill, is that *no* new
binary encoding should be proposed as a standard without a working
group to study what's there, what's needed, what the goals should be,
and what the right approach is to fulfilling those goals.  Am I
correct?

With that model, the answer that your goals are valid but are
different to ours... would not be a valid one -- we would have to
agree on the goals, and only develop a standard that met that
agreement.  Am I correct?

To the rest of the community: Do you agree with that concern?  Do you
think such an analysis and selection of common goals, leading to one
(or perhaps two) new binary encodings being proposed is what we should
be doing?  Or is it acceptable to have work such as CBOR proposed
without that analysis?

Barry

---

From: Martin Thomson <[email-masked]>
Date: Fri, 9 Aug 2013 21:25:51 +0100

> appropriate to publish CBOR as a Proposed Standard, and see who uses

I'm ambivalent on this point.  I don't see CBOR as being useful, but I
don't believe that we should be setting the bar for PS so high that
this doesn't meet it.

> arguments with CBOR?  Do you agree that CBOR is flawed?

PHB's comments were valid.  Though I'll point out that a clear
applicability statement is one potential way to allow something like
this to advance without directly addressing those concerns.  I might
prefer that those concerns be addressed directly, but I also want a
pony.

> be doing?  Or is it acceptable to have work such as CBOR proposed

I'm not 100% convinced either way in this case.  I can see the
potential here for damage in either direction: choose one format and
it might not be applicable in a wide array of valid use cases; or
allow multiple, narrowly-focused formats and end up with no
consistency at all.

(CBOR attempts to cover several branches of the latter case, by
defining a narrowly-focused, but somewhat general-purpose mechanism
that can be arbitrarily extended.)

I'm also highly cynical regarding the ability of a working group to
produce anything that avoids these sorts of problems.  I'm so glad
that I'm not an area director.

---

From: Tim Bray <[email-masked]>
Date: Fri, 9 Aug 2013 13:46:24 -0700

> appropriate to publish CBOR as a Proposed Standard, and see who uses

I have two moderate concerns:

1. I haven’t seen any particularly convincing evidence that CBOR would, in
production, achieve any meaningful reductions in serialization time or
deserialization time or code footprint or memory footprint.
2. I think CBOR does too much; I’d discard half the features and see who
uses *that*.  Well, if it doesn’t take off they can always try CBOR-lite
next year.

But I do not see it as actively harmful, am not screaming or lying down in
the road; go ahead and give it an RFC number and see what happens.

I’d also like to compliment Barry on his restraint and courtesy in dealing
with Phillip here; far more than I would have been able to muster.

 -T

> argue

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Aug 2013 16:56:59 -0400

> Expected by whom?  By me?  No.  By the IESG?  No.  Whom else are you

Actually I just want it in writing because my past experience of a similar
platform type spec was that it was just another option for developers right
up to the point where it was published when I found myself in a BOF where
the members were being told that they 'had' to use the IETF platform for
their work because that is what had been 'decided'.

Understand here that I am not accusing you Barry of doing that but you
won't be AD forever.

> able to get something that can meaningfully be called IETF consensus.

During the discussions there was a clear subset who wanted to have JSON
plus length encoded binary blobs/unicode strings as opposed to CBOR. Would
publication of CBOR as a proposed standard make it less likely that such a
proposal would be acceptable to you?

> *more* than we have had with many working group documents.

I don't see DMARC as being the same as CBOR.

DMARC is primarily a mechanism that has standalone value that is built on
top of S/MIME. CBOR is a proposal that has no value unless other people
choose to build on top of it.

> this.  And, I'll repeat what I've said before: there are no "short

The proposers have maintained full proprietary control of the spec at all
times. They are the only arbiters of what they consider to be the
appropriate design goals. I don't consider the opportunity to state my
complaints to be participation.

> and what the right approach is to fulfilling those goals.  Am I

I think that nothing should be described as an IETF Proposed STANDARD
unless the IETF proposes to use it. I know that the process document is
loosey-goosey on this but I think that until someone takes CBOR and uses it
as a part of a mousetrap that it isn't going to be an IETF proposed
standard regardless of what it says on the RFC.

Publishing a fully specified but untried proposal as EXPERIMENTAL would
seem to me to be exactly the right course for this type of thing. It is
what we are currently doing in HTTP Authentication mechanisms. If any get
traction they can be promoted to Proposed Standard.

I think that the bar to getting something published as a static document
should be pretty low. But the bar for standards track is a little
different.

> agree on the goals, and only develop a standard that met that

I think that the design goals have to be decided with respect to use cases.
I have use cases driven by running code. I don't know what the use cases
are that drive the CBOR design requirements. All I know is that whenever a
proposal is made that Carsten and Paul don't like their response is 'that
is not one of our design goals'.

It might well be that there is a need for more than one binary encoding. It
is possible that my desire to have a binary encoding that can be formally
shown to be equivalent to JSON is not what people want. It might be that
people really do want to have a binary encoding that has the rich type
system of CBOR. There might even be more niches that need to be filled.

But my preferred process would be this

1) Publish any proposal that is fully described as Experimental

2) Wait

3) When the first WG that is going to use a binary encoding of JSON is
ready to emit a specification, revisit the question of which format(s) to
make a standard. If there are multiple groups that have decided to use
different formats we should find out why and if there are sound reasons,
that might lead to yet another format or it might mean that there really is
a need for more than one. If there are multiple groups that have all chosen
the same one then we have a winner. If there is only one group, well make
their choice Proposed Standard and see if path dependence kicks in.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 9 Aug 2013 17:12:38 -0400

> with Phillip here; far more than I would have been able to muster.

Tim, if you want to slam other people on the list, please have the courtesy
to do so directly. Are you really upset about what I said to Barry or what
I said about the defects in the XML specification you led?

The reason I directed those questions at Barry is that I had previously
asked them in private and received no response. I also want the answers to
be on the record. An applicability statement would be a good plan.

The issue here is not whether or not CBOR gets an RFC number but whether
issuing that RFC number means that those of us who made alternative
proposals for a binary encoding are being foreclosed on.

And it does seem rather odd that while I am being told that there are two
opportunities to challenge a Personal Submission, on the initial list and
the IETF list, that I then get criticized for raising the issues on the
IETF list.

For the record, I thought that there was a lot of skepticism about CBOR
from the start. There is certainly a consensus in support of CBOR among
supporters of CBOR but at least half the commenters were negative and the
fundamental question of why CBOR versus a binary version of JSON encoding
was never answered.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Aug 2013 02:42:09 +0200

> 1. I haven’t seen any particularly convincing evidence that CBOR would, in production, achieve any meaningful reductions in serialization time or deserialization time or code footprint or memory footprint.

I'm not sure relative to what you want to see that reduction.

But let me give you a real-world example.

Look at section 6.3.3 of the OMA Lightweight M2M Technical Specification.
This defines a TLV format for multiple-instance resources (whatever that means is not very relevant in this context).  This format is becoming a bit complicated because this is trying to be efficient (in the number of bytes needed).  Being designed from scratch, it also has certain functional deficiencies I don't want to go into here.

If you look closely behind the complexity created by the desire to be efficient, this is actually just a map of maps.  The CBOR representation of that is just as efficient (probably slightly more so) as the bespoke encoding specifically invented for this.  Apart from the direct gains in simplicity and efficiency, in an implementation, the CBOR code is likely to be shared and more polished than the bespoke code for this, so there are likely to be more gains in code size and performance.

Specialized binary formats like this TLV format are invented a dozen a day all over the industry.
Each of them has their own little set of unwarranted complexities, bizarre features, and little bugs waiting to explode in the face of their users.
Rationalizing some of them to a common base like CBOR will be a major win.
(Justifiably or not, JSON isn't even in the starting block for many of them.)

> 2. I think CBOR does too much; I’d discard half the features and see who uses *that*.  Well, if it doesn’t take off they can always try CBOR-lite next year.

In order to address use cases such as the above, CBOR has to have a certain amount of capabilities.
It is indeed a judgment call which capabilities should be included in the standard.
Feedback from people who want to use this in the IETF has led to a little bit of growth compared to the original proposal, but only moderately so.

Grüße, Carsten

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Aug 2013 21:04:17 -0400

On Aug 9, 2013, at 4:56 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Actually I just want it in writing because my past experience of a similar platform type spec was that it was just another option for developers right up to the point where it was published when I found myself in a BOF where the members were being told that they 'had' to use the IETF platform for their work because that is what had been 'decided'.

People say that a lot.   It's true that code reuse is an argument in favor of doing one thing over another, but there are lots of other relevant arguments, not the least of which is "it doesn't work well."   This second argument carries just as much weight as the first.   The bottom line is that there is nothing the IESG can do to prevent people from making this claim, but working group chairs should understand that it is not binding—it's just one thing to consider among many.

I recommend reading RFC 1958.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 10 Aug 2013 02:09:32 +0100

Hi Carsten,

As a no-hats, IETF-LC comment...

> Rationalizing some of them to a common base like CBOR will be a major win.

That, and some of the IETF LC discussion reminds me of BEEP. [1]
While CBOR also seems sensible, maybe being sensible isn't
sufficient for stuff like this.

So some kind of statement that CBOR is one point in a design
space (as opposed to an optimal solution for some set of
design objectives) would be worthwhile. (Or even to make it
EXP and not PS, but to be honest I don't care much about
that distinction here.)

S.

[1] http://tools.ietf.org/html/rfc3080

---

From: Dave Crocker <[email-masked]>
Date: Fri, 09 Aug 2013 19:33:49 -0700

On 8/9/2013 6:09 PM, Stephen Farrell wrote:
> design objectives) would be worthwhile.

huh?  a statement beyond the opening sentence of the introduction and 
its third paragraph?

worthwhile to whom and for what?  it's a spec (or perhaps a meta-spec.) 
  it provides a capability.  it needs to specify the what and how well 
enough to be usable.

while ietf culture permits specifications to have quite a variety of 
commentary, historical or contextual discussion is not an essential part 
of the document, and certainly not discussion cast in a manner to 
denigrate the current spec.

Counter-marketing that has the current spec self-deprecatingly casting 
itself as  only one of many seems mostly worthwhile to get people to 
avoid using it.

exp makes sense if there is doubt that it is technically workable, not 
because its success in the market is questionable.  we give ps all the 
time to specs that have little clear market and go on gain small market use.

from what i've seen, this is a carefully researched and crafted 
mechanism and i haven't noted anyone challenging it on basic technical 
grounds.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 10 Aug 2013 12:13:00 +0100

On 08/10/2013 03:33 AM, Dave Crocker wrote:
> huh?  

That's fair. My suggestion above wasn't a model of clarity;-)

> a statement beyond the opening sentence of the introduction and
> its third paragraph?

And now that I read that again, yes, it does what I was
trying try to ask for well enough.

S.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Aug 2013 08:32:25 -0400

Howdy,
You asked for community input, so I'll pipe up from the peanut gallery.

I happen to be looking for a JSON-ish on-the-wire encoding with binary support, and I actually like what I see in CBOR.  (I'll probably end up using MessagePack anyway though... popularity has a quality all its own)

Comments inline...

> appropriate to publish CBOR as a Proposed Standard, and see who uses

If the intention is to just document an encoding format/mechanism and see who uses it, I think 'Informational' achieves that goal and is more appropriate.  If the intention is to base other standards-track work on this one in the near-term, and you've got some such use-case in mind for it, then 'Proposed Standard' seems reasonable to me if there're no strong objections.  Afaict it's always been easier to move Info to PS later, but it's been a lot harder to deprecate PS.  In the latter you have to prove something's broken/dangerous, while in the former you just have to prove people use it.

Also, while I take Ted's point that people shouldn't feel constrained to use it in other WGs, in practice I find that both WG participants and WG Chairs do in fact give a huge bias to re-using something that's published as a PS.  The burden of proof required to not re-use an existing PS RFC is very high.  They say: "It's a STANDARD!" and the implication is its something written on a stone tablet given to a guy named Moses.

I'm not saying that will happen in this case at all, but we shouldn't kid ourselves that it doesn't matter.  If it didn't matter, people wouldn't care about labeling their IDs Informational or Experimental.  People seem to *want* the PS label, and I don't think it's because people want to upgrade to an IS someday. [as an aside: that's what the 2-level RFC experiment should teach us - that there is only 1 level that people care about, in practice]

> arguments with CBOR?  Do you agree that CBOR is flawed?

No, it doesn't appear to contain technical errors nor fail to meet its self-stated design objectives.  I think Phillip probably has different design objectives.  But I'm not an expert in the field of object encoding theory. :)

> be doing?  Or is it acceptable to have work such as CBOR proposed

I think it's fair to publish CBOR as Informational right now.  I think publishing it as Proposed Standard would be ok if there wasn't strong disagreement, but it appears there is strong disagreement, including on how it came to be.  I have no idea what the history of CBOR's development has been, but if it's truly the case that it's just a couple people's personal work, then that's cool but PS seems wrong to me if a third person says it's a bad design. [again, I have no idea if that's true/false]  

We rarely get 100% agreement even in WGs, but at least in WGs you get focused concentration from many participants.  Usually I've only seen PS going the A-D route when there are no objections from anyone whatsoever. (but that could be a wrong impression)

-hadriel

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Aug 2013 10:21:13 -0400

> I'm not saying that will happen in this case at all, but we shouldn't kid ourselves that it doesn't matter.  If it didn't matter, people wouldn't care about labeling their IDs Informational or Expe…

It almost certainly will happen.   But "we shouldn't do this because someone might later on draw an incorrect conclusion about what we did" is just not a valid argument against advancing the document to proposed standard.   What it is is an argument for understanding the IETF process so that when people make assertions about this sort of thing, you can have a meaningful debate with them and point at RFCs.   Otherwise your working group can get sidetracked by the ownership assertion problem, which as you are already aware can be very damaging.

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 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."

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.

(Dave Thaler will know why I know to reference these two documents... :)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Aug 2013 11:30:43 -0400

> 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…

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:…

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."

> 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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Aug 2013 12:25:37 -0400

> 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 20…

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 I…

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…

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, jus…

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.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Aug 2013 12:41:47 -0400

> 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.

To expand on this slightly, the point is that if you say "it's not clear to me what the use case for this document is," that's a valid objection, and the authors ought to address it, either by explaining to the satisfaction of the consensus-caller and, more generally, the reviewers, why it's not relevant, or by fixing the document to be clearer about what the current intended use cases are.   But if you want that to happen, you should really raise your objection in a way that makes it clearly actionable, so that the authors know you are asking them to do something.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 10 Aug 2013 18:12:56 +0000

> 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…

I don't know about the IESG, but I don't think an encoding mechanism or for that matter any format needs to have a targeted use case. WebSec is currently debating ([1] whether to put the key pinning data in an HTTP header or in a resource. If we choose the latter, there will be the question of encoding, and we will probably consider things like XML, JSON, ASN.1, and CBOR, or roll our own new one-time format. If someone in the group wants to do the one-off format, we will ask why not use XML, JSON, or CBOR (nobody's going to ask about ASN.1, because those that care enough to suggest it also know to call it BER), and of course you'll need a good reason not to use a documented format, whether it's "standard" or not.

Those will be the obvious choices regardless of whether CBOR is Informational, Experimental, PS, or still a draft-bormann. Nobody's proposing technical changes, so we might as well stick an RFC number on it. IMO the only time you stick the "INFORMATIONAL" label on a protocol or an encoding, is when you are just documenting a protocol or an encoding that exists outside the IETF, and the IETF is not given change control. See draft-ietf-websec-x-frame-options for an example. Experimental is for things where we don't know if they work in general or if they scale. IOW, we're not sure they're appropriate for their stated goal. That is not the case with CBOR.

Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning (intended to be PS) with a downref. But just because downrefs exist does not mean we should aim for them. PS is the right choice IMO.

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Aug 2013 20:45:55 +0100

On Sat, Aug 10, 2013 at 3:21 PM, Ted Lemon <[email-masked]> wrote:

> > I'm not saying that will happen in this case at all, but we shouldn't
> kid ourselves that it doesn't matter.  If it didn't matter, people wouldn't
> care about labeling their IDs Informational or Experimental.  People seem
> to *want* the PS label, and I don't think it's because people want to
> upgrade to an IS someday. [as an aside: that's what the 2-level RFC
> experiment should teach us - that there is only 1 level that people care
> about, in practice]
>
> It almost certainly will happen.   But "we shouldn't do this because
> someone might later on draw an incorrect conclusion about what we did" is
> just not a valid argument against advancing the document to proposed
> standard.   What it is is an argument for understanding the IETF process so
> that when people make assertions about this sort of thing, you can have a
> meaningful debate with them and point at RFCs.   Otherwise your working
> group can get sidetracked by the ownership assertion problem, which as you
> are already aware can be very damaging
>

You seem to think that the IETF process is a model of clarity and purpose.
For over a decade the vast majority of IETF standards were not STANDARDs.

It seems rather odd to be referring to 2026 as holly writ here when we have
since changed the process so that there are two steps instead of three.
This being largely to recognize the fact that the contemporary criteria for
PS were far in excess of what the criteria had been twenty years ago.

Standards are what people interpret them as, no more, not less. If the IETF
calls something a cat then people are going to expect it to be a feline
even if RFC 3141.56 says that a 'cat' is actually an umbrella.

The obvious reading of 2026 is that Proposed Standard is a document that
describes something that the IETF is proposing should be a standard and
that the part that David cites states the minimum criteria for documents
that are to be endorsed by the IETF as standards proposals.

Like it or not, the endorsement of the IETF is what the various people who
hire consultants to work on IETF specifications are seeking.

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.
>

It really is neither, it is an experiment, the experiment being to see
whether anyone will use it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Aug 2013 20:55:23 +0100

On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir <[email-masked]> wrote:

> > 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 don't know about the IESG, but I don't think an encoding mechanism or
> for that matter any format needs to have a targeted use case. WebSec is
> currently debating ([1] whether to put the key pinning data in an HTTP
> header or in a resource. If we choose the latter, there will be the
> question of encoding, and we will probably consider things like XML, JSON,
> ASN.1, and CBOR, or roll our own new one-time format. If someone in the
> group wants to do the one-off format, we will ask why not use XML, JSON, or
> CBOR (nobody's going to ask about ASN.1, because those that care enough to
> suggest it also know to call it BER), and of course you'll need a good
> reason not to use a documented format, whether it's "standard" or not.
>
> Those will be the obvious choices regardless of whether CBOR is
> Informational, Experimental, PS, or still a draft-bormann. Nobody's
> proposing technical changes, so we might as well stick an RFC number on it.
> IMO the only time you stick the "INFORMATIONAL" label on a protocol or an
> encoding, is when you are just documenting a protocol or an encoding that
> exists outside the IETF, and the IETF is not given change control. See
> draft-ietf-websec-x-frame-options for an example. Experimental is for
> things where we don't know if they work in general or if they scale. IOW,
> we're not sure they're appropriate for their stated goal. That is not the
> case with CBOR.
>
> Yes, we can reference CBOR as normative from draft-ietf-websec-key-pinning
> (intended to be PS) with a downref. But just because downrefs exist does
> not mean we should aim for them. PS is the right choice IMO.
>

If key pinning was to use CBOR rather than JSON or ASN.1, I think you are
going to be laughed at.

Since pins are to ASN.1 encoded certificates, I think you are obliged to
choose ASN.1 if you want the browser people to implement.

But lets consider the case that you did decide on CBOR. The Working Group
would then be obliged to look at the specification and persuade key
stakeholders to implement the code. And that might result in changes of the
'remove this half of the specification before we will accept it' variety or
the 'we won't implement unless the encoding is ASN.1'.

At the very least it means that the 'design goals' would get a work out.

But why would CBOR be on the table and not BJSON or JSON-B or any of the
other potential choices?

---

From: Yoav Nir <[email-masked]>
Date: Sat, 10 Aug 2013 20:47:00 +0000

On Aug 10, 2013, at 10:55 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Sat, Aug 10, 2013 at 7:12 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

If key pinning was to use CBOR rather than JSON or ASN.1, I think you are going to be laughed at.

Since pins are to ASN.1 encoded certificates, I think you are obliged to choose ASN.1 if you want the browser people to implement.

I think the browser people also have a JSON parser lying around somewhere. But I agree that CBOR would increase the cost of implementation, and that's a good argument against choosing CBOR. It's also a good argument against choosing any new encoding anybody might propose.

But lets consider the case that you did decide on CBOR. The Working Group would then be obliged to look at the specification and persuade key stakeholders to implement the code. And that might result in changes of the 'remove this half of the specification before we will accept it' variety or the 'we won't implement unless the encoding is ASN.1'.

But why would CBOR be on the table and not BJSON or JSON-B or any of the other potential choices?

I don't see why any of them would be off the table.

Yoav

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 10 Aug 2013 16:50:06 -0400

> 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.

> 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 cave…

Ahh, I see.  I did read that sentence but it felt more like an afterthought escape clause. :)
That's good to know though.

-hadriel

---

From: SM <[email-masked]>
Date: Tue, 13 Aug 2013 12:40:36 -0700

>    might result in a change or even retraction of the specification

RFC 2026 also says that "Implementors should treat Proposed Standards 
as immature specifications".  Specifications are rarely 
retracted.  The community would not agree to retract an Experimental 
document.  Trying to do that with a Proposed Standard is madness. :-)

>    that there has been adequate coordination with the standards process

There is a bug in the above.  I prefer to avoid quoting RFC 2026 
nowadays as nobody really knows what RFC 2026; or to say it 
differently, the consensus is that there isn't any consensus about RFC 2026.

At 11:46 10-08-2013, Eliot Lear wrote:
>There is an architectural question hiding here: when we use CBOR in

Note that I did selective quoting.

There is a belief that someone would have thought about the 
architectural question.  After seeing such questions being ignored or 
seeing the blank stares in response to an architectural question I 
prefer not to even ask about that.  It is difficult to find the right 
answer to architectural questions.  One can only wonder how many 
people read RFC 1958 before writing a draft.

Padlipsky's Law states that:

   To The Technologically Naive, Change Equals Progress;
   To Vendors, Change Equals Profit.

I would read The Relevant Literature instead of RFC 2026.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Aug 2013 13:34:47 -0700

On 8/13/2013 12:40 PM, SM wrote:
> nowadays as nobody really knows what RFC 2026; or to say it differently,
> the consensus is that there isn't any consensus about RFC 2026.

Either you are wrong or we have no stable, written criteria that 
determine assignment of our standards labels and our process really is 
quite ad hoc and therefore unreliable.

I hope you are wrong.

d/