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

From: Rob Sayre <[email-masked]>
Date: Mon, 1 Aug 2016 01:04:54 -0700

The issue doesn't seem to matter.

- Rob

On Sun, Jul 31, 2016 at 9:58 PM, Anders Rundgren <
[email-masked]> wrote:

> On 2016-08-01 03:22, Peter F. Patel-Schneider wrote:
>
>> 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
>
>
>
>> 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.
>>>
>>> (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:
>>>
>>>> On 2016-07-28 18:05, Joe Hildebrand (jhildebr) 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.
>>>>
>>>> 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.
>>>>>
>>>>
>>>> I think that helps, but it's not sufficient.
>>>>
>>>> Best regards, Julian
>>>>
>>>> PS: ...and we need a minor revision anyway; see prior feedback.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> json mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/json
>>>> .
>>>>
>>>>
>> _______________________________________________
>> json mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/json
>>
>>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 8 Aug 2016 11:14:54 +0100

Hi,
Here are my comments on the document, most of them are nits:

"Byte order mark" in Section 8.1 needs a definition, for example by including the Unicode codepoint value.

In Section 11: I think you meant to update references to point to this document, not an earlier RFC.

Appendix A needs to be checked that it is correct. I think at least a couple of things are out of date.

First mention of UTF-8, UTF-16 need normative references.

Sent from my iPad