## JSONPath June Interim Minutes   {#jsonpath-june-interim-minutes}

Carsten: We have a PR for iregexp from James Clark, that we should be
allowing  
script references in /p constructs and found W3C regex don't allow that.
He also  
mentioned block references are relatively problematic, James convinced
me we  
shouldn't. Does anyone have an opinion on unicode blocks?

Tim: I am fully supportive of this

Carsten: Can you please review my pull request?

Carsten: Are we going to do a WGLC separately?

James: I would argue they be done separately

Carsten: Will you be the shepherd for the document?

James: Yes, I can volunteer to do it

Carsten: What has been helpful in other WGs is the shepherd doing the
write up  
before WGLC. But we don't have to do it that way.

**Action**: Tim to review the outstanding iregexp PR

**Action**: James to do the document shepherd writeup

### Security Considerations (#185, #186)   {#security-considerations-185-186}

Tim: We still have open issues on this, and PR's correct?

James: #186 is the second pass with your feedback

Tim: Glyn: You edited this most recently?

Glyn: I don't remember

Tim: Let's take 5 minutes to read it and see if we're happy

Carsten: I wouldn't mind adding Tim's text, I think being very explicit
is  
always a good thing.

**Action**: Glyn to do some editorial work to include Tim's proposed
text

Tim: Any other issues on this?

James: Just these I believe

Glyn: Are you ready to close #185?

Tim: Closed

### String Normalisation (#117)   {#string-normalisation-117}

James: Last we concluded was that we wouldn't do it

Tim: I made a PR, and Glyn you merged it

Glyn: We can just add a comment and close it

Carsten: We should have re-read

### Extensions   {#extensions}

James: There was an action in the last meeting to put a starting point
with  
Carsten

Carsten: I don't remember that

Tim: I'm not convinced on this

James: We've talked about this before, what matters is the mechanism not
the  
functionalities individually. There's a few existing proposals that
would  
benefit; we need to define how to extend syntactically, and if not a
clear  
statement saying it's unsupported.

Carsten: #154 is an example, as a general rule if we provide an
extension point  
it's important to exercise it immediately. I'm not sure if we have done
a survey  
of existing implementations, but more importantly we come up with a
solution for  
the next decade or so.

Tim: How would we register extensions?

Carsten: You would just see if the extension is used, no need for
versions.

James: No obligation to implement the extensions.

Glyn: Two different parties could implement the same extension with
different  
semantics?

Carsten: That's for the registry to manage. I would ship this draft with

`.length` (#154) and we would have a registration policy of how things
would be  
added.

Tim: I am probably against this, I hate optional features as you lead to
SQL.

James: We're talked about SQL before - it doesn't have an IANA registry,
we will  
have a controlled mechanised with experts and review, and the document
review  
with IESG and IANA will check this. If we do not provide this
implementations  
will do it anyway, we think that's inevitable due to the demand, and our

standard will be forked to include desired capability.

Glyn: We already have 30 implementations, so I think it's too late

James: I disagree, we shouldn't set the expectation that all
implementations  
have to provide support for all implementations, only the mechanisms for
it. We  
already diverge away from existing implementations.

Tim: Do we have someone to write something on this?

**Action**: Carsten to write an extension proposal to discuss

## Draft Status, Existing Issues...   {#draft-status-existing-issues}

Tim: I'd like to get sense from the group on base draft status?

Carsten: We have 16 issues in Github, most of which can be closed

**Actions**:

*   Glyn to improve associative documentation
*   \#162 to be closed by the editors
*   \#161 Carsten to write comment and close
*   \#117 Tim to close

## Next Meeting, AOB   {#next-meeting-aob}

**Action**: James to send out poll to schedule next interim  
**Action**: James to update milestones