Subject: [Json] Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 18 Jul 2016 12:58:57 +0000

Hello all,

This starts the Working Group Last Call of draft-ietf-jsonbis-rfc7159bis-02, ending on July 31.

Please send all comments to this list ([email-masked]) or the draft author/editor ([email-masked]).  Any and all comments are welcome, including simple statements that this document is ready to progress.

Thank you,

- JSONbis Chair

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Mon, 18 Jul 2016 06:54:50 -0700

My understanding is that ECMA 404 is about to undergo a change, and this
change is important to the changes in rfc7159bis.  If this is the case, then I
believe that rfc7159bis should not have gone to last call, as one of the
document's normative references is in flux and there is no pointer in the
document to even a draft of the new version of the normative document.

Ideally rfc7159bis should not go to last call until there is the equivalent of
a last call version of the revised ECMA 404.

Peter F. Patel-Schneider
Nuance Communications

On 07/18/2016 05:58 AM, Matt Miller (mamille2) wrote:
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2016 16:11:43 +0200

Hi there,

I believe this document needs an Appendix (next to Appendix A) which 
summarizes what's actually different from RFC 7159.

Best regards, Julian

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 18 Jul 2016 16:45:40 +0200

> summarizes what's actually different from RFC 7159.

This gives a whole new meaning to the word "normative"...

Anders

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Jul 2016 15:48:02 +0100

> summarizes what's actually different from RFC 7159.

Correct, this is an IETF requirement on all -bis documents.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Jul 2016 17:11:50 +0200

> This gives a whole new meaning to the word "normative"...

Looking at 
<https://tools.ietf.org/rfcdiff?url2=draft-ietf-jsonbis-rfc7159bis-00.txt>, 
the information is actually there (in Section 1.3). But it is still 
weird that we have an appendix for one but not the other.

To clarify, I'm looking specifically at the change in 
<https://tools.ietf.org/rfcdiff?url2=draft-ietf-jsonbis-rfc7159bis-00.txt#part-4> 
(yeah for anchors in the HTML diff!).

Best regards, Julian

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 18 Jul 2016 17:19:21 +0200

Hi Julian,

Pardon me, I was confusing this with the mentioned changes in EMCA's JSON specification (which hardly is considered as "normative" by the development community and therefore should be left out of the RFC).

Anders

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 19 Jul 2016 09:05:04 +0000

> On Jul 18, 2016, at 15:54, Peter F. Patel-Schneider <[email-masked]> wrote:
> 

The only change planned for ECMA-404 is to reference rfc7159bis by its stable number.  One of them needs to go first; in this case that is rfc7159bis.

--
- m&m

Matt Miller
Cisco Systems, Inc.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Tue, 19 Jul 2016 10:58:04 -0700

> The only change planned for ECMA-404 is to reference rfc7159bis by its stable number.  One of them needs to go first; in this case that is rfc7159bis.

The only change from what?  The only change from the version of ECMA-404
referenced in draft-ietf-jsonbis-rfc7159bis-02?  That document, available at
www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf, doesn't
mention rfc7159bis at all.  If there is a draft version of a revised ECMA-404
that only needs a pointer updated, then that version needs to be made
available so that reviewers of draft-ietf-jsonbis-rfc7159bis-02 can determine
whether this document is suitable for normative use in rfc7159bis.

As far as can be determined from draft-ietf-jsonbis-rfc7159bis-02 there has
been no work on ECMA-404 since October 2013.  It thus appears that all the
changes in rfc7159bis will have to be made and approved before any changes to
ECMA-404 have even been drafted.

peter

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 28 Jul 2016 08:31:11 -0700

This document should not progress further at the current time.  This document
should not even have progressed to last call status.

This document has an unusual normative reference to ECMA-404.  This document
also has wording to the effect that both IETF and ECMA will work to keep the
documents consistent with each other.  The version of ECMA-404 referenced,
http://www.ecma-international.org/publications/standards/Ecma-404.htm, has no
similar commitment from ECMA, nor indeed any reference, normative or
otherwise, to any IETF document at all.

Before this document can progress in its current form there needs to be a
draft of the new version of ECMA-404 that lays out the commitment from ECMA.
The draft needs to be available before the next last-call for this document so
that the commitments stated by ECMA can be checked against the commitments
stated by IETF.

Peter F. Patel-Schneider
Nuance Communications

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 28 Jul 2016 16:05:52 +0000

I agree that the document should not be published as an RFC until we have the equivalent last-call doc from ECMA, and we do a coordinated publish of the two documents.  But having our side ready to go, including finishing AUTH48, will allow us to not be the bottleneck in that process.

I believe we have adequate protections in place with Alexey not pushing the button until the right time, and making sure that the RFC Production Center is aware of the dependency to what amounts to a downref. 

Would it help if we replaced the ECMA-404 reference with a a ref to ECMA-404bis (with details left out)?  That would make it *very* clear to the RPC what we intend, and would trigger processes they have in place to ensure the reference is resolved before publishing.

> On Jul 28, 2016, at 9:31 AM, Peter F. Patel-Schneider <[email-masked]> wrote:
> 

-- 
Joe Hildebrand

---

From: Julian Reschke <[email-masked]>
Date: Thu, 28 Jul 2016 18:13:19 +0200

> I agree that the document should not be published as an RFC until we have the equivalent last-call doc from ECMA, and we do a coordinated publish of the two documents.  But having our side ready to…

Not sure. "approved" means "approved". I believe we need a mechanism 
that makes sure that the update of 404 not only happens, but that it 
also contains the change we expect.

> Would it help if we replaced the ECMA-404 reference with a a ref to ECMA-404bis (with details left out)?  That would make it *very* clear to the RPC what we intend, and would trigger processes they…

I think that helps, but it's not sufficient.

Best regards, Julian

PS: ...and we need a minor revision anyway; see prior feedback.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Thu, 28 Jul 2016 10:56:46 -0700

On 07/28/2016 09:13 AM, Julian Reschke wrote:
>> I agree that the document should not be published as an RFC until we have
>> the equivalent last-call doc from ECMA, and we do a coordinated publish of
>> the two documents.  But having our side ready to go, including finishing
>> AUTH48, will allow us to not be the bottleneck in that process.
> 
> Not sure. "approved" means "approved". I believe we need a mechanism that
> makes sure that the update of 404 not only happens, but that it also contains
> the change we expect.

Yes, how can this document be approved when there is no indication of what
changes are going to be made to ECMA-404?

>> I believe we have adequate protections in place with Alexey not pushing the
>> button until the right time, and making sure that the RFC Production Center
>> is aware of the dependency to what amounts to a downref.
>>
>> Would it help if we replaced the ECMA-404 reference with a a ref to
>> ECMA-404bis (with details left out)?  That would make it *very* clear to the
>> RPC what we intend, and would trigger processes they have in place to ensure
>> the reference is resolved before publishing.
> 

A simple reference to something that doesn't exist isn't going to help much,
if at all.

peter

---

From: Martin J. Dürst <[email-masked]>
Date: Sat, 30 Jul 2016 19:13:44 +0900

I think this is an issue of trust, from both sides. For those not in a 
mood to trust ECMA, I suggest they trust our WG chairs and ADs.

(If everything goes really wrong, we can always issue a revision with 
the reference to the ECMA side removed.)

Regards,   Martin.

On 2016/07/29 01:13, Julian Reschke wrote:
>> I agree that the document should not be published as an RFC until we
>> have the equivalent last-call doc from ECMA, and we do a coordinated
>> publish of the two documents.  But having our side ready to go,
>> including finishing AUTH48, will allow us to not be the bottleneck in
>> that process.
>
>> I believe we have adequate protections in place with Alexey not
>> pushing the button until the right time, and making sure that the RFC
>> Production Center is aware of the dependency to what amounts to a
>> downref.
>>
>> ECMA-404bis (with details left out)?  That would make it *very* clear
>> to the RPC what we intend, and would trigger processes they have in
>> place to ensure the reference is resolved before publishing.
>
> .

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Jul 2016 13:37:22 +0200

+1, well said.

> On 30 Jul 2016, at 12:13 PM, Martin J. Dürst <[email-masked]> wrote:
> 
> I think this is an issue of trust, from both sides. For those not in a mood to trust ECMA, I suggest they trust our WG chairs and ADs.
> 
> (If everything goes really wrong, we can always issue a revision with the reference to the ECMA side removed.)
> 
> Regards,   Martin.
> 

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

---

From: Stefan Hagen <[email-masked]>
Date: Sat, 30 Jul 2016 17:40:20 +0200

+1 dito

--
Stefan.

> Am 30.07.2016 um 13:37 schrieb Mark Nottingham <[email-masked]>:
> 
> +1, well said.
>

---

From: Tim Bray <[email-masked]>
Date: Sat, 30 Jul 2016 23:40:00 -0700

So, I guess the IETF & ECMA representatives will have to meet in the
parking lot of a strip mall in Akron, Ohio, or maybe Lyon, France, and set
up their laptops side by side on the back of a car, and count down:
3-2-1-COMMIT!  Then they’ll shake hands and go their separate ways, while
the gunmen on the nearby rooftops stand down.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 31 Jul 2016 12:01:06 +0100

Hi,

> On 30 Jul 2016, at 11:13, Martin J. Dürst <[email-masked]> wrote:
> 

Indeed. I can always hold publication of RFC until we see a draft version of ECMA document.

So I would encourage WG participants to concentrate on technical content of the document during the WGLC.

---

From: "Peter F. Patel-Schneider" <[email-masked]>
Date: Sun, 31 Jul 2016 18:22:39 -0700

I don't think that trust enters into the equation here.

A standards document, be it from IETF, or from some other organization, should
be complete before being considered for final review.  This is not the case
for draft-ietf-jsonbis-rfc7159bis-02 because one of its normative references
is not available for review in the form that it needs to be to support
draft-ietf-jsonbis-rfc7159bis-02.  Trust in ECMA or WG chairs or ADs is no
substitute for having an actual document to review.

If there is trust involved it would be trusting that ECMA doesn't turn around
and remove the reciprocal language in a future  revision of ECMA-404.

peter

On 07/30/2016 03:13 AM, Martin J. Dürst wrote:
> I think this is an issue of trust, from both sides. For those not in a mood to
> trust ECMA, I suggest they trust our WG chairs and ADs.
>

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 1 Aug 2016 06:58:24 +0200

> I don't think that trust enters into the equation here.

The obvious solution is removing the ECMA reference. Not because
"The IETF has a problem with ECMA", but because the idea of having
two organizations being authoritative/normative for a standard is
pointless unless they work together on a single document.

ECMA should consider referencing the RFC instead of duplicating it.

Anders