Subject: [Json] Benoit Claise's No Objection on draft-ietf-json-i-json-05: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Mon, 19 Jan 2015 06:01:18 -0800

Benoit Claise has entered the following ballot position for
draft-ietf-json-i-json-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-i-json/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There is still a ongoing discussion between J. Schönwälder (OPS-DIR) and
Tim Bray.

On Sun, Jan 04, 2015 at 04:54:55PM -0800, Tim Bray wrote:
> On Sun, Jan 4, 2015 at 12:14 PM, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
>
>> My understanding is that compliance to I-JSON means compliance to
>> section 2 of this document. Perhaps it makese sense to clarify this
>> (in particular if my interpretation is wrong).
>>
>
> Hmm, good point.  ​The draft currently doesn’t mention compliance; all
it
> does is give a syntactic definition of something called an “I-JSON
> message”.  The notion was that other specs which wanted to require the
use
> of I-JSON should say something like “The message body must be an
I-JSON
> message [RFCXXXX]”.  I think that would work fine, but I wonder if
others,
> like you, will be bothered by the absence of a specification of
> “compliance”.
>

I am raising this question since I think the draft goes somewhat
beyond simply defining I-JSON (which I believe is the material
contained in section 2).

In particular, the I-D uses RFC 2119 language in a section titled
"Protocol-design Recommendations". It is not clear to me how these
recommendations have been selected or why they are part of an I-JSON
specification. This applies mostly to sections 4.3 and 4.4. Anyway,
since these sections use RFC 2119 requirements language, I am
wondering what happens if a protocol complies to section 2 but not all
of section 4 - is it using I-JSON? I hope so, but it might be good to
make this clear.

/js

----------------------------------------------------

Editorial nit:

- s/values in in ISO 8601/values in ISO 8601/

---

From: Tim Bray <[email-masked]>
Date: Thu, 22 Jan 2015 17:59:35 -0800

<editor-hat>

My opinion is that while it is perhaps a little unusual not to define
conformance, I don’t think doing so would increase the *usefulness* of the
draft.  The intent is that the draft provide a complete, crisp definition
of an entity called an “I-JSON message” and protocol designers make use of
it by saying that their message payloads “MUST be I-JSON messages”.

It honestly hadn’t crossed my mind that people might want to claim official
conformance with the protocol-design recommendations.  If there’s a
perception that this is a likely scenario, it would not be that difficult
to include a definition of the notion of conformance.

On Mon, Jan 19, 2015 at 6:01 AM, Benoit Claise <[email-masked]> wrote:

> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jan 2015 09:15:32 +0100

Tim,

if a protocol designer writes "MUST be I-JSON messages" (to use your
wording) then I like to know what exactly that means. Is support of
section 2 sufficient for that?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Tim Bray <[email-masked]>
Date: Sun, 25 Jan 2015 10:12:28 -0800

​The WG claim is that Section 2 -
http://www.tbray.org/tmp/draft-ietf-json-i-json-05.html#rfc.section.2​ -
provides sufficient detail that a referring spec can say MUST be I-JSON
Messages, with a reference to that, and this should provide sufficient
clarity.  If it doesn’t, I think the WG would agree that that’s a bug.

On Fri, Jan 23, 2015 at 12:15 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html