Subject: Appeal from Phillip Hallam-Baker on the publication of RFC 7049 on the Standards Track

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Feb 2014 17:49:37 -0500

During the November IETF meeting, I received an appeal from Phillip
Hallam-Baker to the publication of CBOR, RFC 7049, on the Standards
Track.  (Procedural note: The appeal was, at this point, to me as the
responsible AD, and has not gone to the IESG.)  Phill is questioning
the process; specifically, Phill's appeal is as follows:

-------------------------- start --------------------------
My issue here is more than a preference for one encoding over another,
the manner in which CBOR was made a standard has negated the value of
having it being proposed as a standard.

There are already five JSON in binary encodings in widespread use.
CBOR offers no particular advantages over any of the existing schemes
and the authors have never been willing to explain why a different
encoding is desirable.

An IETF standard would have had the advantage of being a single choice
that people could use but only if it was capable of meeting all the
requirements that might be raised and only if it was genuinely
supported by IETF consensus.

Using the individual submission process to shortcut the process
suggests that you don't consider the technical differences between
encodings very important. An encoding is a foundational piece f work
that requires an open process because other people are going to be
building on it.

- CBOR is more complex than JSON and introduces a different data
model. It reintroduces features such as definite/indefinite length
encodings that have already been found to be defective in ASN.1.

- CBOR is an alternative to JSON encoding and not as many people
supported on the APPs list, a simple extension that adds in the
functionality of length delimited strings and binary blobs.

- CBOR does not support compression of tags or strings and there is no
way in which it can be extended to support this capability. It can
however be extended to support new intrinsic types such as a new type
of integer or float. Which is precisely the type of extensibility JSON
rejects.

Had there been an open process, those of us who had requirements and
code that depended on the requirements could have raised them and
there would have been a possibility of a single output from the work.
Instead CBOR does nothing to address the problem of multiple encoding
options and only adds another option on the table.
--------------------------- end ---------------------------

I've taken an unusually long time to resolve this, and for that delay
I apologize and appreciate Phill's patience on -- his appeal did come
in within the two-month appeal window after the approval announcement.

As I evaluated the appeal, I reviewed every message in the discussion
threads.  In the end, my conclusion is that I support the appeal.  I
think that Phill is right that we should have had open discussion of
the design criteria before considering a specific proposal for an
encoding.  The result of not having done that was that we approved an
encoding scheme that meets certain use cases and design goals, without
having first discussed what use cases and design goals the community
might want to have covered.

I think it's important for ADs to consider, when deciding to sponsor
non-working-group documents, whether a broader design discussion is
appropriate.  I believe that I made a mistake in not considering that
for this case.

As to a remedy, I do not see that changing the status of RFC 7049 --
for example, moving it from Standards Track to Experimental -- would
be in the best interest of the IETF at this point.  CBOR had a good
deal of interest when it was proposed, and that interest has continued
and is resulting in implementations (see http://cbor.io/impls.html for
one list of what's going on with respect to CBOR implementations).  A
change to RFC 7049 now would not likely change anything, and would
result in time wasted in moving it back to Standards Track at a
suitable time.

I thank Phill for persisting in pointing out what I missed, and I
intend to consider this more strongly in future decisions about
sponsoring potential standards.

Barry, Applications AD

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Feb 2014 19:47:14 -0500

> sponsoring potential standards.
I will just add that I did not appeal because I have my own proposal. I
wrote the JSON-B proposal because I was being told that CBOR was a private
proposal that did not want input from people with different requirements.

https://tools.ietf.org/html/draft-hallambaker-jsonbcd-01

Choice of encoding format has some very important consequences for
security, particularly when working in non-managed languages like C.

Further the reason that I think a specification should start off as
Experimental in this case is that then the promotion from Experimental to
Proposed has significance and can build momentum.

We already had a half dozen 'JSON in binary proposals' before CBOR. The
design choices in CBOR don't seem to me to be noticeably better than BJSON
and the rest. Adding to the pile of me-too proposals does not help matters.
The only thing that could improve matters is if we reached a consensus on
one choice. And that cannot happen when the authors reject ideas or
requirements that are not their own.

Finally there are people suggesting that CBOR is the IETF version of JSON
in Binary. It isn't and now it never can be. Not least because it does not
follow the JSON data model and thus isn't technically interchangeable. It
is not possible to go back and create consensus after people are told 'this
is our ball, we choose who we are going to play with' as happened in this
case.

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

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 19 Feb 2014 11:16:55 -0700

On 2/18/14 5:47 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

>in Binary. It isn't and now it never can be. Not least because it does
>not follow the JSON data model and thus isn't technically
>interchangeable. It is not possible to go back and create consensus after
>people are told 'this is our ball, we choose who we are going to play
>with' as happened in this case.

Barry, can you add a little more clarity on this point, please?  Does your
decision mean that we shall not ever normatively reference CBOR in future
protocols?

-- 
Joe Hildebrand

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Feb 2014 13:56:04 -0500

> decision mean that we shall not ever normatively reference CBOR in future

It does not mean that.  CBOR does remain as a Proposed Standard.  This
is about process, and the key point is here:

> we should have had open discussion of
> encoding.
...
> appropriate.  I believe that I made a mistake in not considering that

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Feb 2014 14:50:38 -0500

--On Wednesday, February 19, 2014 13:56 -0500 Barry Leiba
<[email-masked]> wrote:

>> Barry, can you add a little more clarity on this point,
>> please?  Does your decision mean that we shall not ever
>> normatively reference CBOR in future protocols?
> 
> It does not mean that.  CBOR does remain as a Proposed
> Standard.  This is about process, and the key point is here:

Barry,

Purely as a process clarification (I don't care enough one way
or the other, but I haven't been involved in JSON work), is it
correct that, if someone wanted the state that Joe asked about
(i.e., no normative references to CBOR), they would need to take
one of the following three steps:

(1) Appeal your just-announced decision, asking that the
document be reclassified to Experimental, Informational, or, I
suppose, Historic?

(2) Generate an I-D specifying one of the above four results and
the reasons for it and try to get that I-D approved.

(3) Generate an I-D for an Applicability Statement that would
identify CBOR as "not recommended" and try to get it approved.
While that would not prevent a normative reference requiring
CBOR use, it would certainly touch off an interesting discussion
should anyone try to do it.

In either the second or third cases, the parties involved could
either try to get the I-D through the process as an individual
submission or could try to get some relevant WG, presumably (but
not required to be) JSON, to take it into their work program[me].

Does that correctly summarize the process alternatives?

    john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Feb 2014 15:10:27 -0500

> document be reclassified to Experimental, Informational, or, I

If someone really thought it was in the best interest of the IETF to
reclassify the document, yes, they could appeal my decision; talking
to the IETF Chair would be the proper path.

> the reasons for it and try to get that I-D approved.

That would be an alternative path to getting the document reclassified.

Reclassifying the document would not stop anyone from using it as a
normative reference, now that we permit downrefs.

> should anyone try to do it.

A "CBOR Considered Harmful" document would be a more extreme case of (2), yes.

> Does that correctly summarize the process alternatives?

It seems like it.  I imagine that, creative sorts that we are, we
could manage to come up with other wrinkles.  As I've said, I think
none of them are in our best interest at this point.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Feb 2014 16:10:55 -0500

> As a matter of process, I'm confused about the handling of this appeal.
> It sounds like Phil appealed the approval of RFC 7049.
>
> That, I hope, was a decision made by the IESG, not a decision made by
> one AD.
> So, I'm failing to understand how it makes sense for you to respond to
> this appeal as an AD.

Phill took the first step of addressing his complaint to the
responsible AD (me).  This is my response.  If he or someone else
should choose to pursue a further appeal, the next step would be to
take it to the IESG by way of the Chair.

Barry

---

From: S Moonesamy <[email-masked]>
Date: Wed, 19 Feb 2014 13:48:52 -0800

Hi Barry,
>take it to the IESG by way of the Chair.

Selective quoting:

   "During the November IETF meeting, I received an appeal from Phillip
    Hallam-Baker to the publication of CBOR, RFC 7049, on the Standards
    Track."

RFC 7049 was published in October 2013.  As Sam Hartman mentioned it 
was a decision of the IESG.

   "Phill is questioning the process;"

That falls under the IESG.

The handling of the appeal is odd.

Regards,
S. Moonesamy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Feb 2014 19:37:18 -0500

On Wed, Feb 19, 2014 at 4:48 PM, S Moonesamy <[email-masked]> wrote:

> RFC 7049 was published in October 2013.  As Sam Hartman mentioned it was a
> decision of the IESG.
>

The whole process has been odd.

I told Jari and Barry that I was appealing the decision in Vancouver. I was
told to raise it with the relevant AD first. By the time he had come to a
decision it was that too much effort had gone into building things on top
of CBOR since to undo the original decision.

I now realize that what I should have done was to simply send the original
appeal to the IETF list and not gone through channels as requested.

The fundamental problem here is that as I see it the protocol world is
rapidly converging on JSON as the encoding of choice and there are many
good reasons why it is a better encoding than any of the text based
alternatives on offer (RFC822, XML). It is thus inevitable that people will
ask if a binary encoding of JSON would be better than ASN.1. Which of
course is true and not just because hitting yourself on the foot repeatedly
with a hammer is better than ASN.1.

JSON is good for a lot of things, but not for passing encrypted objects
around unless they are really small. So JOSE is interesting but only in a
very limited field. If we can encode binary data in JSON without a 33%
inflation in size, JOSE suddenly becomes very interesting indeed.

If JOSE didn't inflate the size of a data object, we could use it for data
level encryption. Drop a content type tag and some other metadata on the
wrapper, encrypt the contents and we can have a CMS like blob that fits the
Internet idiom much better (and there is some soon to expire IP that would
make animating that proposal very interesting).

But now we have a binary encoding published on IETF standards track that is
not a binary encoding of JSON but has a subset that could be used to encode
JSON sitting in that spot. It isn't a consensus document, isn't a product
of open process, it is however on IETF standards track. So the job for
anyone doing the job properly has become harder.

So it is kind of like the Sochi which will always be the OoOo* Olympics.

The only thing that makes an encoding interesting is that a constituency of
users agree to all make use of it. JSON has emerged from a field of
thousands of text encodings because it is the best compromise between
simplicity and functionality that has such a wide user base. So having
random specs given standards status when the designers only attempted to
solve the problems they cared about does not help matters.

My main concern is the process question. I really don't care whether CBOR
is a PROPOSED STANDARD or whatever. What I do care about is if I am told
that I have to use it because that is the IETF standard for binary
encoding. And what I care most about is the risk that this approach of 'its
our ball and only we will decide who gets to play' is going to be repeated.

There are cases where it makes perfect sense for a draft to go straight
onto the standards track. There are plenty of extensions to PKIX that are
important enough to write down but not so important that it is worth
running up a whole working group just to decide them.

But a spec whose only purpose is to provide a platform for other specs
really needs to clear a higher bar than not being idiotic and having some
people willing to implement. There have to be people who want to choose to
build on it.

The way I think the process should work is:

1) The IAB identifies the need for a consensus binary encoding for JSON as
a platform the IETF community can build on (or why call it an architecture
board).

2) People write drafts that elaborate on the requirements and/or propose
schemes that meet them, these are published as either EXPERIMENTAL or
INFORMATIONAL.

3) People who are building applications that build on the platform kick the
tires and decide which ones they like / hate etc. Either a consensus
emerges that one encoding is best in which case we can go to step 4,
otherwise we go back to step 2.

4) PROPOSED STANDARD status is awarded in recognition of the fact that
there is a defacto standard that application protocol designers have
converged on. This may involve spinning up a working group to clean up the
documents or not depending on their quality.

I have seen the shotgun standards approach in the past. BEEP tried that
route, it was a complete failure as a result because it moved through the
standards process so fast it never gained any buy in outside the original
design team. So even though it has features that are very sound and the
HTTP/2.0 WG might well end up re-inventing it was still born because the
proposers thought that standards track was the route to driving adoption
rather than recognition of adoption.

Standards is the process of making decisions that don't matter. It does not
really matter what the HTTP protocol syntax is provided that a decision has
been made to choose one syntax for that task instead of five.

So I would like to see the IAB actually doing the job of an architecture
board and identifying gaps in the IETF stack where convergence on one
particular way of solving a problem would be beneficial. That is not saying
that they should be the people providing the solution.

---

From: Tim Bray <[email-masked]>
Date: Wed, 19 Feb 2014 16:48:15 -0800

> a platform the IETF community can build on (or why call it an architecture

It’s not obvious that such a consensus exists.  In my experience, message
parsing times are dominated by memory management and network pipes are
congested by multimedia files and wrapping binary blobs in general-purpose
data packaging formats is usually the wrong thing to do anyhow for a
variety of reasons.  Thus, I question the utility of a binary encoding of
JSON.  Examining the trial of tears that went into the attempts to make a
“binary XML” would be instructive in this context.

---

From: <[email-masked]>
Date: Thu, 20 Feb 2014 00:51:11 +0000

The process has not been odd.

The outcome has been expedient.

Different thing.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Phillip Hallam-Baker [[email-masked]]
Sent: 20 February 2014 00:37
To: S Moonesamy
Cc: Barry Leiba; Sam Hartman; IETF Discussion Mailing List
Subject: Re: Appeal from Phillip Hallam-Baker on the publication of RFC 7049 on the Standards Track

On Wed, Feb 19, 2014 at 4:48 PM, S Moonesamy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Barry,

Selective quoting:

RFC 7049 was published in October 2013.  As Sam Hartman mentioned it was a decision of the IESG.

I told Jari and Barry that I was appealing the decision in Vancouver. I was told to raise it with the relevant AD first. By the time he had come to a decision it was that too much effort had gone into building things on top of CBOR since to undo the original decision.

I now realize that what I should have done was to simply send the original appeal to the IETF list and not gone through channels as requested.

The fundamental problem here is that as I see it the protocol world is rapidly converging on JSON as the encoding of choice and there are many good reasons why it is a better encoding than any of the text based alternatives on offer (RFC822, XML). It is thus inevitable that people will ask if a binary encoding of JSON would be better than ASN.1. Which of course is true and not just because hitting yourself on the foot repeatedly with a hammer is better than ASN.1.

JSON is good for a lot of things, but not for passing encrypted objects around unless they are really small. So JOSE is interesting but only in a very limited field. If we can encode binary data in JSON without a 33% inflation in size, JOSE suddenly becomes very interesting indeed.

If JOSE didn't inflate the size of a data object, we could use it for data level encryption. Drop a content type tag and some other metadata on the wrapper, encrypt the contents and we can have a CMS like blob that fits the Internet idiom much better (and there is some soon to expire IP that would make animating that proposal very interesting).

But now we have a binary encoding published on IETF standards track that is not a binary encoding of JSON but has a subset that could be used to encode JSON sitting in that spot. It isn't a consensus document, isn't a product of open process, it is however on IETF standards track. So the job for anyone doing the job properly has become harder.

The only thing that makes an encoding interesting is that a constituency of users agree to all make use of it. JSON has emerged from a field of thousands of text encodings because it is the best compromise between simplicity and functionality that has such a wide user base. So having random specs given standards status when the designers only attempted to solve the problems they cared about does not help matters.

My main concern is the process question. I really don't care whether CBOR is a PROPOSED STANDARD or whatever. What I do care about is if I am told that I have to use it because that is the IETF standard for binary encoding. And what I care most about is the risk that this approach of 'its our ball and only we will decide who gets to play' is going to be repeated.

There are cases where it makes perfect sense for a draft to go straight onto the standards track. There are plenty of extensions to PKIX that are important enough to write down but not so important that it is worth running up a whole working group just to decide them.

But a spec whose only purpose is to provide a platform for other specs really needs to clear a higher bar than not being idiotic and having some people willing to implement. There have to be people who want to choose to build on it.

1) The IAB identifies the need for a consensus binary encoding for JSON as a platform the IETF community can build on (or why call it an architecture board).

2) People write drafts that elaborate on the requirements and/or propose schemes that meet them, these are published as either EXPERIMENTAL or INFORMATIONAL.

3) People who are building applications that build on the platform kick the tires and decide which ones they like / hate etc. Either a consensus emerges that one encoding is best in which case we can go to step 4, otherwise we go back to step 2.

4) PROPOSED STANDARD status is awarded in recognition of the fact that there is a defacto standard that application protocol designers have converged on. This may involve spinning up a working group to clean up the documents or not depending on their quality.

I have seen the shotgun standards approach in the past. BEEP tried that route, it was a complete failure as a result because it moved through the standards process so fast it never gained any buy in outside the original design team. So even though it has features that are very sound and the HTTP/2.0 WG might well end up re-inventing it was still born because the proposers thought that standards track was the route to driving adoption rather than recognition of adoption.

Standards is the process of making decisions that don't matter. It does not really matter what the HTTP protocol syntax is provided that a decision has been made to choose one syntax for that task instead of five.

So I would like to see the IAB actually doing the job of an architecture board and identifying gaps in the IETF stack where convergence on one particular way of solving a problem would be beneficial. That is not saying that they should be the people providing the solution.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 19 Feb 2014 16:59:14 -0800

> The outcome has been expedient.

Maybe not.  In the IETF, an expedient outcome is pretty odd.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 20 Feb 2014 12:28:10 +1100

> My main concern is the process question. I really don't care whether CBOR is a PROPOSED STANDARD or whatever. What I do care about is if I am told that I have to use it because that is the IETF sta…

I have to agree with Phillip on this point, and I hope the answer is uncontroversial -- that just by virtue of being an IETF standard, we don't start requiring people to use something already defined if their use case is vaguely similar. 

When something is a standard, it means you need to use it in the way specified; it doesn't mean you have to choose to use it, even in other standards.

That's not to say we shouldn't encourage people to examine, improve, etc. existing standards when we feel that their uses can be addressed by them; it's just that we don't have a "highlander rule," and for the health of the Internet I think that's a good thing.

If this is indeed the case, I think Phillip's concerns about the process are perhaps notable, but people are still free to define, use and standardise other approaches to binary JSON, so it shouldn't be an issue.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: S Moonesamy <[email-masked]>
Date: Wed, 19 Feb 2014 20:18:12 -0800

Hi Phillip,
At 16:37 19-02-2014, Phillip Hallam-Baker wrote:
>I told Jari and Barry that I was appealing the decision in 
>Vancouver. I was told to raise it with the relevant AD first. By the 
>time he had come to a decision it was that too much effort had gone 
>into building things on top of CBOR since to undo the original decision.
>
>I now realize that what I should have done was to simply send the 
>original appeal to the IETF list and not gone through channels as requested.

The RFC was published before the Vancouver meeting.  There was a 
four-weeks Last Call before that.  This was an extremely late 
appeal.  There were some red flags during the Last Call.  I assumed 
that somebody would have noticed them and done something about that.

>But now we have a binary encoding published on IETF standards track 
>that is not a binary encoding of JSON but has a subset that could be 
>used to encode JSON sitting in that spot. It isn't a consensus 
>document, isn't a product of open process, it is however on IETF 
>standards track. So the job for anyone doing the job properly has 
>become harder.

I'll suggest writing a (technical) draft about the topic and getting 
it published by the ISE.

>1) The IAB identifies the need for a consensus binary encoding for 
>JSON as a platform the IETF community can build on (or why call it 
>an architecture board).
>
>2) People write drafts that elaborate on the requirements and/or 
>propose schemes that meet them, these are published as either 
>EXPERIMENTAL or INFORMATIONAL.
>
>3) People who are building applications that build on the platform 
>kick the tires and decide which ones they like / hate etc. Either a 
>consensus emerges that one encoding is best in which case we can go 
>to step 4, otherwise we go back to step 2.
>
>4) PROPOSED STANDARD status is awarded in recognition of the fact 
>that there is a defacto standard that application protocol designers 
>have converged on. This may involve spinning up a working group to 
>clean up the documents or not depending on their quality.

[snip]

>So I would like to see the IAB actually doing the job of an 
>architecture board and identifying gaps in the IETF stack where 
>convergence on one particular way of solving a problem would be 
>beneficial. That is not saying that they should be the people 
>providing the solution.

The reason for a charter is to inform people of the work which will 
be done.  In practice, most people do not pay attention to that.

I don't think that (2) and (3) is workable as it can lead to 
polarized discussions where it would be difficult to reach 
agreement.  By the way, (4) is what Internet Standard is supposed to be.

Regards,
S. Moonesamy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 20 Feb 2014 08:22:30 +0100

<no hat>
> When something is a standard, it means you need to use it in the way specified; it doesn't mean you have to choose to use it, even in other standards.

Yeah, we're off the rails here, and it's becoming a bad habit.  People
seem to like playing "what if" games about how bad things can get if
everyone loses their heads.  WGs and spec developers should always use
what makes sense (standard or no).  Rough consensus and running code,
thank you very much.

Eliot

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2014 09:11:55 -0500

On Feb 19, 2014, at 4:10 PM 2/19/14, Barry Leiba <[email-masked]> wrote:

> responsible AD (me).  This is my response.

So, to clarify the process, Phill did not submit an appeal to the IESG under section 6.5 of RFC 2026.  Rather, he took his complaint directly to you.

As an aside at this point - is there a formal description of this complaint to you as an "appeal"?  If so, where is the process documented?

Phill's complaint appears to be directed at the IESG process: "My issue here is [...] the manner in which CBOR was made a standard has negated the value of having it being proposed as a standard."  You wrote: "his appeal did come in within the two-month appeal window after the approval announcement."  Yet Phill's complaint/appeal appears to have been handled solely by you, rather than through the process described in section 6.5 of RFC 2026.

I'm not arguing with what has been described as an expedient outcome.  Barry has responded unilaterally to Phill's complaint and not as a part of a formal appeal by Phill; Phill is satisfied with that response and has not, to date, filed a formal appeal.  If I have that right, then Barry should clarify that this complaint/response was not part of the formal appeals process.  For example, here:

>  If he or someone else
> take it to the IESG by way of the Chair

Barry should make clear that Phill would be taking up a formal appeal under RFC 2026, after following an informal discussion of his complaint with the responsible AD.

My concern is that we not establish some de facto extension to our processes by labeling this particular example of complaint resolution as a formal appeal.

- Ralph

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Feb 2014 09:46:03 -0500

On Thu, Feb 20, 2014 at 9:11 AM, Ralph Droms <[email-masked]> wrote:

> So, to clarify the process, Phill did not submit an appeal to the IESG
> under section 6.5 of RFC 2026.  Rather, he took his complaint directly to
> you.
>
> As an aside at this point - is there a formal description of this
> complaint to you as an "appeal"?  If so, where is the process documented?
>

It was an appeal because I advise the IETF chair that I wished to make an
appeal and I followed the procedure that he advised me to take and the AD
advised me to take.

I don't believe that I should be the one looking through books to find out
what the correct appeals process is.

My complaints are as follows:

1) I was prevented from contributing to what purports to be an IETF
proposed standard.

2) I made complaints about this in last call

3) I was effectively denied the ability to appeal.

So yes, I do insist that this be listed as an appeal in the plenary and
that the outcome is listed as 'it was botched'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Feb 2014 10:40:20 -0500

On Thu, Feb 20, 2014 at 2:22 AM, Eliot Lear <[email-masked]> wrote:

> >> My main concern is the process question. I really don't care whether
> CBOR is a PROPOSED STANDARD or whatever. What I do care about is if I am
> told that I have to use it because that is the IETF standard for binary
> > I have to agree with Phillip on this point, and I hope the answer is
> uncontroversial -- that just by virtue of being an IETF standard, we don't
> start requiring people to use something already defined if their use case
> is vaguely similar.
> >
> > When something is a standard, it means you need to use it in the way
> specified; it doesn't mean you have to choose to use it, even in other
> standards.
>

Oddly enough, compact formats for protocol encodings are one specification
that never need to be implemented to have value.

Back in the XKMS vs SCVP days a journalist tried to compare the two specs.
Since all they understood was the message size, that was the basis for
comparison. An SCVP message is maybe 1KB and an XKMS message might be as
much as 3KB (I am guessing here).

Given that both easily fit into an IP packet and they involve public key
cryptography, the size of the message would be completely irrelevant even
if the two protocols were equivalent (which they are not). But the story
was taken up and used as FUD.

If we had has a compact encoding for XML, we could have easily defeated the
FUD by pointing out that people who care can use the efficient encoding
option and the 'problem' goes away.

The issue can also come up at the design stage. Earlier this morning
someone proposed the following as an example of a JSON microformat:

microformat GPSLocation;
   // A GPSLocation is a pair of comma separated floating-point
   // numbers representing longitude and latitude.
   // e.g. "location": "0.0,51.5"

But this is not using JSON encoding at all, it is a string with two decimal
fractions separated by a coma. The JSON encoding would be:

"location" : {"X":0.0,"Y":51.5}

The justification for the microformat is of course byteshaving. And of
course the example being artificial is unrepresentative. In the normal case
the comparison would be

"210.012345,51.52232" vs {"X" : 210.012345,"Y" : 51.52232}

The difference is 3 control bytes versus 9 for the tagged version. Which
isn't actually a lot of overhead for a tagged text format.

But imagine we have an efficient binary encoding that can represent those
numbers in 5 bytes rather than 10. The efficient binary encoding is much
more efficient than the handcoded binary.

Having a compact binary notation about provides a tool that can be swung
when someone is messing about with a microformat that is only going to
cause grief. If a specification is using JSON encoding then it should use
JSON encoding, not JSON plus a bunch of poorly thought out ad hoc hacks
that seemed like a good idea at the time.

When people reach for regular expressions I reach for the sick bag.

Regular expressions are a very powerful tool that can be used to create
more complexity in fewer lines of code than any other language I know
(including APL). They are like using GOTOs. Every non-trivial program
without exception has GOTO statements but in a structured programing
language the programmer does not code them directly or need to.

So one of the challenges in using XML or JSON or any other regular data
encoding in a standards effort is to block attempts to sneak in other
encodings by way of 'microformats' that always looks such a good idea till
they have to be coded.

Having a binary encoding for the data encoding at hand allows the
microformats to the swatted away. Doing better than a text encoding is
pretty easy. Doing better than a well designed binary encoding is actually
hard.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 19 Feb 2014 15:36:41 -0500

---

From: Barry Leiba <[email-masked]>
Date: Thu, 20 Feb 2014 13:27:18 -0500

I appreciate people's concerns about how this was handled; let me
explain my view of it a bit more.

In his complaint, Phill re-raised an issue he had raised during last
call (and during earlier discussion).  That all happened well before
the IESG got the document.  I interpreted his complaint, then, as
questioning the decisions I made, rather than the publication decision
that the IESG made.

Now, how to handle that:
RFC 2026 Section 6.5.1 covers complaints about working group issues,
but says nothing about handling non-working group, AD-sponsored stuff.
 I decided that the right path was to go back to basic principles:

1. 2026 does seem to guide us to start all complaints with a review by
the person or body that made the decision, a "please reconsider"
request.

2. We should treat all complaints seriously, and make an honest effort
to understand the complaint and address it fairly.

I believe we did both of those, and that handling this, at the first
level, as a complaint about a decision I made (I accepted the document
for AD sponsorship without having been diligent enoughin my
consideration, or I made a judgment about consensus during last call
without having adequately considered the issues Phill raised... you
pick; they amount to the same thing).  For timing, I considered the
IESG approval announcement as when the clock started, because that was
when it became publicly clear that Phill's concern was not going to be
further addressed.

It's perhaps a valid interpretation that this should have been handled
purely as a process appeal, only involving RFC 2026 Section 6.5.2.
For the reasons above, I didn't, and don't interpret it that way.

What do we call this?  Is it an "appeal"?  Well, 2026 doesn't use the
word "appeal" until the "disagreement" (the word 2026 uses) is taken
to the full IESG.  I think that's a distinction with no substance.
Phill wanted his issue addressed, and *he* called it an appeal.  I'm
happy to call it an appeal as well, and see no value in quibbling
about how we refer to it.  In any case, he was asking us to reconsider
a decision.  He was asked to start that by coming to me.  He did, and
I did.  I think that was right, and not in any way "odd".

By handling it this way, we also have not closed off any other
avenues.  Appeal to the IESG is still an open option -- clearly, I
think it's not the best way at this point, and I appreciate that Phill
is willing to accept my response.

What's said in the plenary is up to Jari, but I certainly encourage
him to list this complaint in the plenary, to call it an appeal and to
summarise my response to it.

Now: can we let this discussion settle down?  We had a complaint from
a participant that was taken seriously.  The decision it involved was
reconsidered and responded to.

(And let's please move technical discussion about binary encodings to
another subject thread.)

Thanks, everyone.
Barry

---

From: S Moonesamy <[email-masked]>
Date: Thu, 20 Feb 2014 11:30:39 -0800

Dear IESG,
At 06:11 20-02-2014, Ralph Droms wrote:
>My concern is that we not establish some de facto extension to our 
>processes by labeling this particular example of complaint 
>resolution as a formal appeal.

I share the concern that the IESG will establish the case at 
http://www.ietf.org/mail-archive/web/ietf/current/msg86168.html as a 
extension to the processes if it is labelled as a formal appeal.

There was the following comment from Hadriel Kaplan during the Last 
Call ( http://www.ietf.org/mail-archive/web/ietf/current/msg81414.html ):

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

It was clear to the IESG that there appeared to be strong 
disagreement.  I'll highlight the following from Section 6.5.2 of RFC 2026:

   "The IESG is the principal agent of the IETF for this purpose, and it
   is the IESG that is charged with ensuring that the required procedures
   have been followed, and that any necessary prerequisites to a standards
   action have been met."

I have the following question:

      Is it the responsibility of the IESG to respond to an appeal 
about a process
      issue once a draft has gone through an IETF Last Call?

Regards,
S. Moonesamy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Feb 2014 16:08:17 -0500

It may have been clear to the IESG that there was disagreement. That is not
a barrier to adoption of a specification.

What is a barrier is when the disagreement comes from a statement from the
original proposers of the project that they are not interested in
addressing a set of requirements that are normally considered for a
proposal of that type and that they will ignore all attempts to raise those
requirements or proposals to meet them regardless of the merits.

It was not clear to the IESG that this was the case because it was not
clear to the AD that it was the case.

The IETF has a long tradition of publishing closed development efforts as
RFCs. But those RFCs are expected to be INFORMATIONAL. Had the AD and IESG
been aware of the nature of the consensus backing CBOR it is unlikely that
it would have agreed on PROPOSED STANDARD.

An appeal was raised. If you think that the process has to be followed or
bad things will result then you should insist that the IESG address the
matter in an official capacity to avoid the setting of the precedent you
want to avoid.

I find it rather interesting that there has been more concern about the
correct way to handle the non-handling of the appeal than there ever was
about the rather minor changes to the specification I proposed that could
have avoided the need for process questions at all.

I also find it rather interesting that people who don't have a need to
efficiently transport binary blobs of data about are so committed to making
it difficult for me to do that with a specification that is as close to
JSON as possible. If I have a 1Gb video file that I want to shove down a
pipe, I certainly don't want to add another 333MB of overhead just to use
JSON. Nor do I want to have a protocol that requires me to deal with two
different data models, two different encoders and two different parsers
when I can meet the exact same need by adding tags to JSON to give me a
length bounded chunk encoding.

Such an encoding is not JSON but it is close enough to JSON that I can use
one set of tools to encode/decode both formats. That is not true if I use
the JSON subset of CBOR.

On Thu, Feb 20, 2014 at 2:30 PM, S Moonesamy <[email-masked]> wrote:

>> processes by labeling this particular example of complaint resolution as a
>> formal appeal.
>>
>
> There was the following comment from Hadriel Kaplan during the Last Call (
> http://www.ietf.org/mail-archive/web/ietf/current/msg81414.html ):
>
> It was clear to the IESG that there appeared to be strong disagreement.
>  I'll highlight the following from Section 6.5.2 of RFC 2026:
>
>      Is it the responsibility of the IESG to respond to an appeal about a
> process

---

From: S Moonesamy <[email-masked]>
Date: Fri, 21 Feb 2014 01:23:08 -0800

Hi Phillip,
At 13:08 20-02-2014, Phillip Hallam-Baker wrote:
>An appeal was raised. If you think that the process has to be 
>followed or bad things will result then you should insist that the 
>IESG address the matter in an official capacity to avoid the setting 
>of the precedent you want to avoid.

The only way I can insist that the IESG address the matter is if I 
can convince one or more Area Directors that I might be able to 
recall [2] them if they do not address the matter.

>I find it rather interesting that there has been more concern about 
>the correct way to handle the non-handling of the appeal than there 
>ever was about the rather minor changes to the specification I 
>proposed that could have avoided the need for process questions at all.

The only recourse available to me in the case of an arbitrary 
decision [2] is the the appeal process.  I might not get any help if 
I do not know the correct way for an appeal.  If I do not know the 
process the only choice left to me would be to accept an arbitrary decision.

Regards,
S. Moonesamy

1. http://tools.ietf.org/html/draft-moonesamy-nomcom-eligibility-01
2. There is an informative comment at 
http://www.ietf.org/mail-archive/web/diversity/current/msg00269.html