Subject: [Json] Outstanding Issues for 4627bis

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 20 Sep 2013 16:44:11 +0000

Hello all,

The chairs again thank Douglas Crockford for his contributions to date, especially for the original RFC 4627.  We also thank Tim Bray for taking on editing 4627bis, and getting revision -03 published.  Everyone please review the latest revision and post any comments you have.

The chairs are interested to know the Working Group's opinion on what issues still exist for 4627bis.  There is active discussion on further refining numeric precision and Unicode terminology.  Are there others that need to be addressed?

-- Paul Hoffman and Matt Miller

---

From: "Manger, James H" <[email-masked]>
Date: Sat, 21 Sep 2013 15:00:18 +1000

RFC 4627 doesn't define how URI fragments work for application/json content.

It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

--
James Manger

> ----------
> Subject: [Json] Outstanding Issues for 4627bis
> ...
> The chairs are interested to know the Working Group's opinion on what
> issues still exist for 4627bis.  There is active discussion on further
> refining numeric precision and Unicode terminology.  Are there others
> that need to be addressed?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Sep 2013 08:46:49 -0700

<no hat>

> It would be helpful for 4627bis to say that a fragment (that begins with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we don't do it as part of the -bis because it is not really a clarification. This update can be done with a separate draft that updates the registry, but I admit that people tend to just read the RFCs, not the registry and therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Sep 2013 17:59:44 +0200

> How do others feel about making a change in the -bis that is "things that have happened since 4627" that don't change the JSON grammar?

Uneasy, if the intention is normative.
My other question would be:
Are we ready to say that RFC 6901 is *the* fragment identifier syntax for JSON?

RFC 6901 actually says:

   In
   particular, the fragment identifier syntax for application/json is
   not JSON Pointer.

I don't know enough about the history of that sentence to understand whether that is a statement of fact (obviously true at the time) or a statement of intention.

Grüße, Carsten

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 09:11:23 -0700

This is a bad idea. JSON pointer was designed for a narrow patch use case,
and can't disambiguate objects and arrays.

The JSON RFC shouldn't list every RFC that uses JSON.

- Rob

<no hat>

On Sep 20, 2013, at 10:00 PM, "Manger, James H" <
[email-masked]> wrote:

> It would be helpful for 4627bis to say that a fragment (that begins with
a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer identifies
a specific value in a JSON text.

Changing the IANA MIME registry entry can be done, but I propose that we
don't do it as part of the -bis because it is not really a clarification.
This update can be done with a separate draft that updates the registry,
but I admit that people tend to just read the RFCs, not the registry and
therefore this is likely to be missed.

How do others feel about making a change in the -bis that is "things that
have happened since 4627" that don't change the JSON grammar?

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Sep 2013 10:00:13 +1000

> I don't know enough about the history of that sentence to understand whether that is a statement of fact (obviously true at the time) or a statement of intention.

It was a statement of fact at the time; we couldn't retroactively change the fragment identifier syntax for JSON without a much broader mandate.

Regards,

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

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 23 Sep 2013 20:33:14 -0700

JSON Pointer was designed for multiple purposes, including as a fragment
identifier in URIs.

On Mon, 2013-09-23 at 09:11 -0700, R S wrote:

> This is a bad idea. JSON pointer was designed for a narrow patch use
> case, and can't disambiguate objects and arrays.
> 
> > It would be helpful for 4627bis to say that a fragment (that begins
> with a "/" or is empty) is a JSON Pointer [RFC 6901]. A JSON Pointer
> identifies a specific value in a JSON text.
> 
> Changing the IANA MIME registry entry can be done, but I propose that
> we don't do it as part of the -bis because it is not really a
> clarification. This update can be done with a separate draft that
> updates the registry, but I admit that people tend to just read the
> RFCs, not the registry and therefore this is likely to be missed.
> 
> How do others feel about making a change in the -bis that is "things
> that have happened since 4627" that don't change the JSON grammar?
> 
> --Paul Hoffman

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 20:41:56 -0700

Who designed it?

Anyway, it is buggy as a general purpose fragment identifier.

- Rob
On Sep 23, 2013 8:34 PM, "Paul C. Bryan" <[email-masked]> wrote:

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

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 23 Sep 2013 20:42:29 -0700

It was designed by the JSON Schema working group.

On Mon, 2013-09-23 at 20:41 -0700, R S wrote:

>         JSON Pointer was designed for multiple purposes, including as
>         a fragment identifier in URIs.
>         
>         > This is a bad idea. JSON pointer was designed for a narrow
>         > patch use case, and can't disambiguate objects and arrays.
>         > 
>         > > It would be helpful for 4627bis to say that a fragment
>         > (that begins with a "/" or is empty) is a JSON Pointer [RFC
>         > 6901]. A JSON Pointer identifies a specific value in a JSON
>         > text.
>         > 
>         > Changing the IANA MIME registry entry can be done, but I
>         > propose that we don't do it as part of the -bis because it
>         > is not really a clarification. This update can be done with
>         > a separate draft that updates the registry, but I admit that
>         > people tend to just read the RFCs, not the registry and
>         > How do others feel about making a change in the -bis that is
>         > "things that have happened since 4627" that don't change the
>         > JSON grammar?
>         > 
>         > --Paul Hoffman

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 20:49:25 -0700

> It was designed by the JSON Schema working group.

Oh, I see. That credit doesn't appear in RFC 6901.

Still seems buggy as a general-purpose fragment identifier, since it can't
distinguish between arrays and objects.

- Rob

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 23 Sep 2013 20:49:38 -0700

Kris Zyp was one of the two leads in the JSON Schema working group, and
whose contributions are attributable. He is co-author of RFC 6901.

On Mon, 2013-09-23 at 20:49 -0700, R S wrote:
> Still seems buggy as a general-purpose fragment identifier, since it
> can't distinguish between arrays and objects.
> 
> 
> - Rob
> 
> 
>  
>         
>         
>         >         JSON Pointer was designed for multiple purposes,
>         >         including as a fragment identifier in URIs.
>         >         
>         >         > This is a bad idea. JSON pointer was designed for
>         >         > a narrow patch use case, and can't disambiguate
>         >         > objects and arrays.
>         >         > 
>         >         > > It would be helpful for 4627bis to say that a
>         >         > fragment (that begins with a "/" or is empty) is a
>         >         > JSON Pointer [RFC 6901]. A JSON Pointer identifies
>         >         > Changing the IANA MIME registry entry can be done,
>         >         > but I propose that we don't do it as part of the
>         >         > -bis because it is not really a clarification.
>         >         > This update can be done with a separate draft that
>         >         > updates the registry, but I admit that people tend
>         >         > to just read the RFCs, not the registry and
>         >         > How do others feel about making a change in the
>         >         > -bis that is "things that have happened since
>         >         > 4627" that don't change the JSON grammar?
>         >         > 
>         >         > --Paul Hoffman

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 20:57:24 -0700

> whose contributions are attributable. He is co-author of RFC 6901.

Sure, sure.

What about the other point?

- Rob

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 24 Sep 2013 14:04:36 +1000

> can't distinguish between arrays and objects.

Why does this make it buggy as a fragment id?

A JSON pointer might not be suitable for generating new JSON so that a given pointer doesn't refer to nothing. For example, given {"a":1} and a pointer /b/2, you could add "b":{"2":true} or "b":[0,1,2] so /b/2 points to something.

However, a JSON pointer is perfectly unambiguous for selecting an existing value from a JSON text -- which is the primary use case for a fragment id.

A fragment id for an XML doc that pick the element with a matching id attribute seems sensible. I don't think it is buggy just because the fragment id alone doesn't indicate whether the element is a <p> or <div>, or is inside a <section>.

--
James Manger

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 21:07:21 -0700

> Why does this make it buggy as a fragment id?

It is straightforwardly unsound.

> A fragment id for an XML doc that pick the element with a matching id
> attribute seems sensible. I don't think it is buggy just because the
> fragment id alone doesn't indicate whether the element is a <p> or <div>,
> or is inside a <section>.
>

A better comparison would be an XPath syntax that couldn't distinguish
between an attribute and an element.

- Rob

---

From: "Paul C. Bryan" <[email-masked]>
Date: Mon, 23 Sep 2013 21:08:28 -0700

The Application Area Working group raised and addressed the question of
ambiguity during review of the Internet-Drafts. It concluded, by
consensus, that it was not a substantive issue, despite your
protestations.

On Mon, 2013-09-23 at 20:57 -0700, R S wrote:
>         Kris Zyp was one of the two leads in the JSON Schema working
>         group, and whose contributions are attributable. He is
>         co-author of RFC 6901.
> 
> 
> Sure, sure.
> 
> 
>         > Still seems buggy as a general-purpose fragment identifier,
>         > since it can't distinguish between arrays and objects.
>         > 
>         > 
>         > - Rob
>         > 
>         > 
>         >  
>         > 
>         >         
>         >         
>         >         >         > On Sep 20, 2013, at 10:00 PM, "Manger,
>         >         >         > James H"
>         >         >         > <[email-masked]> wrote:
>         >         >         > 
>         >         >         > > RFC 4627 doesn't define how URI
>         >         >         > fragments work for application/json
>         >         >         > content.
>         >         >         > >
>         >         >         > > It would be helpful for 4627bis to say
>         >         >         > that a fragment (that begins with a "/"
>         >         >         > or is empty) is a JSON Pointer [RFC
>         >         >         > 6901]. A JSON Pointer identifies a
>         >         >         > specific value in a JSON text.
>         >         >         > 
>         >         >         > Changing the IANA MIME registry entry
>         >         >         > can be done, but I propose that we don't
>         >         >         > do it as part of the -bis because it is
>         >         >         > not really a clarification. This update
>         >         >         > can be done with a separate draft that
>         >         >         > updates the registry, but I admit that
>         >         >         > people tend to just read the RFCs, not
>         >         >         > the registry and therefore this is
>         >         >         > likely to be missed.
>         >         >         > 
>         >         >         > How do others feel about making a change
>         >         >         > in the -bis that is "things that have
>         >         >         > happened since 4627" that don't change
>         >         >         > the JSON grammar?
>         >         >         > 
>         >         >         > --Paul Hoffman

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 21:16:21 -0700

On Mon, Sep 23, 2013 at 9:08 PM, Paul C. Bryan <[email-masked]> wrote:

> ambiguity during review of the Internet-Drafts. It concluded, by consensus,
> that it was not a substantive issue, despite your protestations.
>

I agree that the WG agreed to use it.

It did not get IETF consensus as a general-purpose JSON fragment
identifier, and the RFC contains text saying exactly that: "the fragment
identifier syntax for application/json is not JSON Pointer."

Feel free to argue the actual technical point, btw.

- Rob

---

From: John Cowan <[email-masked]>
Date: Tue, 24 Sep 2013 00:22:40 -0400

R S scripsit:

> > Why does this make [JSON Pointer] buggy as a fragment id?
> 

Inspecting a Posix path doesn't tell you if its referent is a device,
a directory, or a file.  Is this also "straightforwardly unsound"?
It's generally considered a virtue.

> between an attribute and an element.

They aren't comparable.  XML labels nodes, whereas JSON (like Posix
paths) labels edges.  A JSON Pointer tells you which edges to traverse
to get to the anonymous value at the end, whereas an XPath tells you
which nodes to traverse to get to a specific named and typed node.

-- 
But the next day there came no dawn,            John Cowan
and the Grey Company passed on into the         [email-masked]
darkness of the Storm of Mordor and were        http://www.ccil.org/~cowan
lost to mortal sight; but the Dead
followed them.          --"The Passing of the Grey Company"

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Sep 2013 06:24:24 +0200

> On Mon, Sep 23, 2013 at 9:04 PM, Manger, James H <[email-masked]> wrote:

You keep saying that, and we keep explaining that there is no need (really: no point) for type checking in a fragment identifier.

> A better comparison would be an XPath syntax that couldn't distinguish between an attribute and an element.

That would indeed be buggy (actually: ambiguous in certain cases), as XML allows to have one element to have an attribute and a subelement of the same name.

A JSON data item can only be an array *or* a map ("object").  There is no need (no point) for a path element in a fragment identifier to indicate which of the two is desired.  In particular, there is no ambiguity (a term that you keep throwing around).

I understand that one may have an aesthetic preference for distinguishing array indexing from map indexing,  But, at the engineering level, that is about as useful as distinguishing indexing in even length arrays from indexing odd length arrays.

Grüße, Carsten

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Sep 2013 13:30:09 +0900

For the record, this specific issue was discussed in the appsawg.

Regards,   Martin.

On 2013/09/24 13:04, Manger, James H wrote:
> A fragment id for an XML doc that pick the element with a matching id attribute seems sensible. I don't think it is buggy just because the fragment id alone doesn't indicate whether the element is a<p>  or<div>, or is inside a<section>.
>
> --
> James Manger

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 21:53:00 -0700

On Monday, September 23, 2013, Carsten Bormann wrote:

>
> I understand that one may have an aesthetic preference for distinguishing
> array indexing from map indexing,  But, at the engineering level, that is
> about as useful as distinguishing indexing in even length arrays from
> indexing odd length arrays.
>

At the engineering level, it may be useful to distinguish between ordered
and unordered collections.

Anyway, it isn't within this WG charter's scope to obsolete RFC 6901. Let
me remind you, that RFC reads: "the fragment identifier syntax for
application/json is not JSON Pointer."

and, as Mark wrote:

"we couldn't retroactively change the fragment identifier syntax for JSON
without a much broader mandate."

that is, the WG didn't have the mandate to specify a general purpose JSON
fragment identifier. That makes sense, since every argument in that WG was
along the lines of "well, we're just trying to make this work for our
little use case." I can link you to those emails if you want.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 24 Sep 2013 07:04:54 +0200

On Sep 24, 2013, at 06:53, R S <[email-masked]> wrote:

> the WG didn't have the mandate to specify a general purpose JSON fragment identifier.

Which is exactly why I asked "are we sure we want to do this now?".

(I don't have an opinion whether the JSON WG is currently chartered to define the fragment identifier for application/json.  Ignoring the specifics of our current charter, it would clearly be in the remit of a JSON WG.)

All I wanted to point out is that the decision not to do type checking is not a suitable technical argument against adopting RFC 6901 as *the* JSON fragment identifier syntax.

> [...] I can link you to those emails if you want.

If there are more consequential technical shortcomings of RFC 6901 as a fragment identifier syntax for JSON, it might indeed be useful for this WG to know.

Grüße, Carsten

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 24 Sep 2013 15:26:42 +1000

> Anyway, it isn't within this WG charter's scope to obsolete RFC 6901.
> Let me remind you, that RFC reads: "the fragment identifier syntax for
> "we couldn't retroactively change the fragment identifier syntax for
> JSON without a much broader mandate."

The whole idea is that this JSON-specific IETF WG has the broader mandate.
This WG is updating the RFC that defines and registers application/json,
which is precisely where the fragment syntax for the media type needs to
be specified.

> that is, the WG didn't have the mandate to specify a general purpose
> JSON fragment identifier.

I disagree. The WG did specify JSON pointer as a general purpose JSON
fragment identifier. Publishing the JSON pointer syntax (which can be
used in lots of places), and modifying the application/json registration
are distinct tasks. It was easier for RFC 6901 "JSON Pointer" to only
do the former, leaving the latter to a more appropriate forum -- which
is this WG at this time.

Nobody can use any fragment syntax with app./json interoperably at the
moment, as none is defined for this media type -- despite media types
and URI fragments being a core components of our web architecture.

As a bonus we can say the fragment syntax is a JSON pointer if, and only if,
the fragment starts with a "/" (or is empty). That leaves room for other
app./json fragment schemes in future if required.

--
James Manger

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 22:38:13 -0700

On Mon, Sep 23, 2013 at 10:26 PM, Manger, James H <
[email-masked]> wrote:

> Publishing the JSON pointer syntax (which can be

That is incorrect. RFC 6901 explicitly rules itself out of being the
application/json fragment identifer syntax: "the fragment identifier syntax
for application/json is not JSON Pointer." Could that be any clearer?

- Rob

---

From: John Cowan <[email-masked]>
Date: Tue, 24 Sep 2013 01:45:49 -0400

> for application/json is not JSON Pointer." Could that be any clearer?

It merely says that was true as of last April.  There is no reason to
suppose that it will be true into the indefinite future, as it can be
overridden by a later RFC at any time.

-- 
The experiences of the past show                John Cowan
that there has always been a discrepancy        [email-masked]
between plans and performance.                  http://www.ccil.org/~cowan
        --Emperor Hirohito, August 1945

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 22:52:15 -0700

> overridden by a later RFC at any time.

"The JSON working group will have as its only initial task the minor
revision of RFC 4627 to bring it onto the Standards Track. As noted
above, RFC 4627 is a mature and widely cited specification. The work is
essentially a reclassification in place, with minimal changes. The
working group will review errata and update the document as needed to
incorporate those, and will correct significant errors and
inconsistencies, but will keep changes to a minimum."

Let's entertain all intellectually-honest interpretations of that text that
include defining a fragment identifier syntax in URIs which can't
distinguish between the two core JSON data structures.

- Rob

---

From: Tim Bray <[email-masked]>
Date: Mon, 23 Sep 2013 22:53:59 -0700

Whether or not this WG/charter combo is empowered to decree #fragment
semantics for the application/json media type is a matter for our
chairs/ADs.

But I have to admit that this one scares me.  Because people will notice
and they’ll start using it.  One of the things I like about JSON-based APIs
is that they’re simple and and have few degrees of freedom.  People are
going to start working the #fragment into API specifications and this has
to me the smell of plenty enough rope for self-hanging.  -T

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 24 Sep 2013 15:57:29 +1000

Tim,
Do you not like fragment ids with any media type? Or is there some reason why they might be worse for JSON in particular?

--
James Manger

From: Tim Bray [mailto:[email-masked]]
Sent: Tuesday, 24 September 2013 3:54 PM
To: John Cowan
Cc: R S; Carsten Bormann; Manger, James H; [email-masked]
Subject: Re: [Json] json-pointer as URI fragment syntax for application/json

Whether or not this WG/charter combo is empowered to decree #fragment semantics for the application/json media type is a matter for our chairs/ADs.

But I have to admit that this one scares me.  Because people will notice and they’ll start using it.  One of the things I like about JSON-based APIs is that they’re simple and and have few degrees of freedom.  People are going to start working the #fragment into API specifications and this has to me the smell of plenty enough rope for self-hanging.  -T

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Sep 2013 16:11:51 +1000

> app./json fragment schemes in future if required.

Exactly.

---

From: R S <[email-masked]>
Date: Mon, 23 Sep 2013 23:23:11 -0700

On Mon, Sep 23, 2013 at 11:11 PM, Mark Nottingham <[email-masked]> wrote:

> > The WG did specify JSON pointer as a general purpose JSON
> > fragment identifier.
>
> Exactly.

No, this is wrong. The WG specified what the draft says, which is: ""the
fragment identifier syntax for application/json is not JSON Pointer."

If it were otherwise, that would mean some important-sounding person could
come along and say "oh, no, what we actually specified was _______". Surely
that would never happen in the IETF.

- Rob

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Sep 2013 17:02:44 +0900

> Anyway, it isn't within this WG charter's scope to obsolete RFC 6901.

There is no need to obsolete RFC 6901. The IETF clearly distinguishes 
between "obsoletes" and "updates".

> Let

Yes, that would be the sentence that would be updated (not by changing 
the sentence itself, but by specifying something different to what it says).

> that is, the WG didn't have the mandate to specify a general purpose JSON

That was the APPSA WG. This is the JSON WG.

> That makes sense, since every argument in that WG was

As far as I remember, the arguments were along the same lines as the 
ones we have seen so far in this mailing list. The use case of a 
fragment identifier is fragment identification. It may well be that JSON 
Pointer isn't suited for some particular tasks, but I haven't yet seen 
an argument as to why it is not suited for the task of fragment 
identification.

As for the claims that JSON Pointer isn't suited for some particular 
tasks, I'd like such claims to be a bit more specific that "can't 
distinguish between array and object" or "may be useful to distinguish 
between ordered and unordered collections". They sound nice and somewhat 
plausible, but they don't show where the rubber hits (or misses) the road.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 24 Sep 2013 17:35:06 +0900

On 2013/09/24 14:52, R S wrote:

> include defining a fragment identifier syntax in URIs

It says that changes should be kept to a minimum, so this is a strong 
argument to not add anything about fragment identifier syntax. However, 
"keep changes to a minimum" doesn't mean no changes at all.

If the WG (and later the IETF) came to the conclusion that e.g. it would 
be better to include the definition (by reference) of a fragment 
identifier syntax in the JSON base specification, e.g. because that 
wouldn't fit well in a "best practices" document and it wouldn't make 
sense to republish the JSON spec (which is after all the 
application/json spec) yet again under a new charter just with the 
fragment identifier bit added.

In some way, this might be done just by rechartering the WG slightly 
before sending the current work deliverable to the IESG, or by including 
the fragment identifier bit as something anticipated to be included in 
the new charter. The WG and IETF last calls could even be sent out 
explicitly noting this fact. This would just be a way to avoid useless 
carter and/or document churn. Another solution is of course to process a 
tiny charter update that adds the the fragment identifier deliverable to 
the charter.

All the above discussion is mostly for the chairs and the ADs to decide 
on. I just wrote it to make clear that the IETF works by (rough) 
consensus, and the legalistic bit can be dealt with if necessary 
(preferably the easier, the better).

Of course, what's most important is what the WG and the IETF wants.

> which can't

Which isn't needed for fragment identification in about the same way 
Ruby (and other programming languages) don't have a problem with not 
distinguishing between Arrays and Hashes on access.

Please, please show us a JSON document together with a json pointer 
fragment identifier where there is an ambiguity as to what the json 
pointer points to.

Regards,   Martin.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 24 Sep 2013 22:20:58 +0000

It does not appear there is any consensus to incorporate JSON pointer, although it seems premature to declare one way or another.  It is also not clear that this proposal is addressing a significant error or inconsistency in either RFC4627 or ECMA-262.

However, the overall goal of this Working Group is to produce an update to JSON that improves interoperability.  If the lack of a syntax for URI fragments is harming interoperability, then defining one would seem to be within the scope of the current charter.

To that end, anyone willing to propose specific texts to incorporate into 4627bis -- whether for JSON pointer or another syntax -- might help the Working Group come to some consensus.  We also need to understand whether or not the lack of a syntax for URI fragments is actually harming interoperability, so discussion of this is still in scope for the WG.

- Paul Hoffman and Matt Miller