Javascript Object Notation
charter-ietf-json-02

[Ballot comment]
I suspect I know what a streamable sequence of JSON texts is, but it's a bit unclear, and would be nice if it were stated in a tiny bit more detail.

[Ballot comment]
I'm not really convinced that these new specs add much value over the base JSON spec (the streaming one in particular).  But they don't seem harmful either.

[Ballot comment]
I wish all charters were this short. I salute you all.

I looked at the draft that will be used as a starting point, and didn't see a list of interoperability issues ("what problem are we trying to solve?").

Are those issues well known in the community, so there's no reason to write them down?

Is anyone likely to raise issues that aren't addressed in the current draft?

[Ballot comment]
To answer Pete's question, I think it would be "nice" to inform Ecma of this pending re-chartering.  I do not know all the politics of the interactions, but it seems that such notification could be seen as a sign of willingness on behalf of the IETF to work with them. Can I assume that Ecma is not on the new-work list?

[Ballot comment]
I am ambivalent about external review. On the one hand, these activities are really IETF internal. On the other, we've been trying to develop a liaison relationship with Ecma. Input on this question welcome.

[Ballot comment]
There is an ambiguity in the charter. I am OK with this ambiguity (and given the likelihood I'm going to be responsible AD for this group, I had better be), but I wanted to make sure that the IESG was crystal clear on this: Paragraphs 4 & 5 indicate that the WG has a "goal" of a "reclassification in place, with minimal changes", and then list fixing errata, and correcting errors and inconsistencies as such minimal changes. However, this charter does not explicitly disallow other changes. It would *not* be a charter violation for the WG to come to consensus that a change that neither fixes an erratum nor corrects an error/inconsistency (e.g., a completely new feature) is nonetheless an acceptable change to make. I'm OK with that, but I want to make sure that everybody else understands that to be the case.

[Ballot comment]
Nit...

"It makes sense to move RFC 4627 onto the Standards Track."

Of course it makes sense, but I don't know that it really needs to said
in the charter (are there other parts of the charter that don't make
sense ;-)

[Ballot comment]
Probably a detail, but it puzzles me. Maybe I read too much into this...

"Any changes that break compatibility with existing implementations of either RFC 4627 or
the ECMAScript specification will need to have very strong justification
and broad support."

Versus

"Any changes that break compatibility with the RFC 4627 or
the ECMAScript specifications will need to have very strong justification
and broad support."

Is this intentional that you mention the existing implementations of RFC 4627?
Do you expect discrepancies between the "existing implementations of RFC 4627" and the "RFC 4627 specifications" (and ECMAScript specification btw)?
The way it's written implies that the existing implementations are the reference versus the specifications.

[Ballot comment]
I wonder if we know how the mechanics of joint publication with
ECMA will work out. I think everyone regretted doing that with W3C
for xmldsig even though there was good will on all sides afaik, and
that it'd be better if the WG just published the RFC having checked
with ECMA at WGLC  and IETF LC. Note - I don't object to the
idea of joint publication, I'm just wary that it might turn into a
swamp of conflicting rules about copyright, IPR and when stuff
happens in each process that could add significant delay and
uncertainty and might give any folks in the rough far too much
opportunity for fun.

A possibly stupid idea if you do want to stick with joint publication:
Add something to the milestones which causes a joint publication
of early on to debug the joint publication thing.
Feel free to entirely ignore that though.

[Ballot comment]
I wonder if we know how the mechanics of joint publication with
ECMA will work out. I think everyone regretted doing that with W3C
for xmldsig even though there was good will on all sides afaik, and
that it'd be better if the WG just published the RFC having checked
with ECMA at WGLC  and IETF LC. Note - I don't object to the
idea of joint publication, I'm just wary that it might turn into a swamp
of conflicting rules about copyright, IPR and when stuff happens in
each process that could add significant delay and uncertainty and
might give any folks in the rough far too much opportunity for fun.

A possibly stupid idea if you do want to stick with joint publication:
Add something to the milestones which causes a joint publication
of early on to debug the joint publication thing.
Feel free to entirely ignore that though.

[Ballot comment]
I wonder if we know how the mechanics of joint publication with ECMA
will work out. I think everyone regretted doing that with W3C for xmldsig
even though there was good will on all sides afaik, and that it'd be better
if the WG just published the RFC having checked with ECMA at WGLC
and IETF LC. Note - I don't object to the idea of joint publication, I'm just
wary that it might turn into a swamp of conflicting rules about copyright,
IPR and when stuff happens in each process that could add significant
delay and uncertainty and might give any folks in the rough far too much
opportunity for fun.

A possibly stupid idea if you do want to stick with joint publication: Add
something to the milestones which causes a joint publication of early on to debug the joint publication thing. Feel free to
entirely ignore that though.

[Ballot comment]

I wonder if we know how the mechanics of joint publication with ECMA will
work out. I think everyone regretted doing that with W3C for xmldsig even
though there was good will on all sides afaik, and that it'd be better if the
WG just published the RFC having checked with ECMA at WGLC and
IETF LC. Note - I don't object to the idea of joint publication, I'm just
wary that it might turn into a swamp of conflicting rules about copyright,
IPR and when stuff happens in each process that could add significant
delay and uncertainty and might give any folks in the rough far too much
opportunity for fun.

A possibly stupid idea if you do want to stick with joint publication: Add
something to the milestones which causes a joint publication of early on to debug the joint publication thing. Feel free to
entirely ignore that though.