Draft: draft-ietf-jsonpath-base

Commentary: Weirdly , I can not reply to this observation :  is somewhat unusual for IANA registries ( early allocations do expire ) . What is the behavior you would expect implementations to exhibit ? The function extension to stop working on the expiry day ? 
 Hey based on this useful - looking discussion , do you plan to revise this significantly ? I 'm wondering if I should give it a careful read now or wait for an updated version . 
 Definitely . Of course , I 'd like to have your input on the points raised ( the non - trivial ones ) . We might even want to have a design - team meeting ... 
 Might be a good idea to mark the non - non - trivial issues above resolved , to help reviewer focus . If it 's OK , I 'll wait for the next revision to go end - to - end . Agreed on a design meeting . 
 Here 's my list of items where we could use input : More frugal with allowing whitespace ? return value of functions that do n't get the right arguments ( e.g. , length(1 ) ) ( interaction with -- non - singular paths in exist - expr ) IANA designated expert instructions ( frugal with " good " names ) expiring reservations ? ( shades of certificates ) domain of length ( arrays now , add strings , objects ? ) ? should there be another function for the size of nodelists ( size ( ) ) ? Probably mostly resolved : for function names ( ASCII , lowercase , only ) 
 I rebased this and resolved some conflicts . 
 Update : Address whitespace in a separate PR , if desired . Semantic issue : What to do with value of wrong kind ? Fixed in Fixed in Probably not . Semantic issue : What to do with value of wrong kind ? Yes , that is called count ( ) now ( ) Let 's stick with that name space . 
 We may be able to make this syntactically invalid . See for some ideas .
Paragraph (version A):
Strings on the right-hand side of the "=~" regex matching operator
MUST conform to I-D.draft-ietf-jsonpath-iregexp.
Paragraph (version A):
The syntax of regular expressions in the string-literals on the
right-hand side of "=~" is as defined in I-D.draft-ietf-jsonpath-
iregexp.
Paragraph (version A):
A regular-expression test yields true if and only if the value on the
left-hand side of "=~" is a string value and it matches the regular
expression on the right-hand side according to the semantics of I-
D.draft-ietf-jsonpath-iregexp.
Paragraph (version A):
The semantics of regular expressions are as defined in I-D.draft-
ietf-jsonpath-iregexp.
Paragraph (version B):
Beyond the filter expression functionality defined in the preceding
subsections, JSONPath defines an extension point that can be used to
add filter expression functionality: "Function Extensions".
Paragraph (version B):
A function extension defines a registered name (see iana-fnex) that
can be applied to a sequence of zero or more arguments, resulting in
a result.  A function-expression stands for ("returns") a nodelist or
a value.  The arguments are filter expressions that are to be
interpreted as nodelists or values.  For each argument and for the
result, the function extension defines the "kind" of the item, i.e.,
whether the item is a value or a nodelist ("nodes").
Paragraph (version B):
Syntactically, a function-expression can occur anywhere where a
singular-path can occur (exist-expr, comparable).  A function-
expression that employs a function extension that returns a nodelist
MUST return a singular node to be used in a comparable.
Paragraph (version B):
Its only argument is a value (possibly taken from a singular path as
in the example above).  The result also is a value, an unsigned
integer.
Paragraph (version B):
If the argument value is a string, the result is the number of
Unicode scalar values in the string.
Paragraph (version B):
If the argument value is an array, the result is the number of
elements in the array.
Paragraph (version B):
If the argument value is an object, the result is the number of
members in the object.
Paragraph (version B):
For any other argument value, the result is one.
Paragraph (version B):
The "match" function extension provides a way to check whether (the
entirety of, see search below) a given string matches a given regular
expression, which is in I-D.draft-ietf-jsonpath-iregexp form.
Paragraph (version B):
Its first argument is a string that is matched against the iregexp
contained in the string that is the second argument.  The result is
"true" if the string matches the iregexp and "false" otherwise.
Paragraph (version B):
The "search" function extension provides a way to check whether a
given string contains a substring that matches a given regular
expression, which is in I-D.draft-ietf-jsonpath-iregexp form.
Paragraph (version B):
Its first argument is a string that is searched for at least one
substring that matches the iregexp contained in the string that is
the second argument.  The result is "true" if such a substring
exists, "false" otherwise.
Paragraph (version B):
There are two kinds of segment: child segments and descendant
segments.
Paragraph (version B):
This specification defines a new "Function Extensions sub-registry"
in a new "JSONPath Parameters registry", with the policy "expert
review" (BCP26).
Paragraph (version B):
The experts are instructed to be frugal in the allocation of function
extension names that are suggestive of generally applicable
semantics, keeping them in reserve for functions that are likely to
enjoy wide use and can make good use of their conciseness.  The
expert is also instructed to direct the registrant to provide a
specification (BCP26), but can make exceptions, for instance when a
specification is not available at the time of registration but is
likely forthcoming.  If the expert becomes aware of function
extensions that are deployed and in use, they may also initiate a
registration on their own if they deem such a registration can avert
potential future collisions.
Paragraph (version B):
Other attacks can target the behavior of underlying technologies such
as UTF-8 (see RFC3629) and the Unicode character set.