From stefan@goessner.net Fri Feb 2 05:27:42 2024 Return-Path: X-Original-To: auth48archive@ietfa.amsl.com Delivered-To: auth48archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0626BC19330B; Fri, 2 Feb 2024 05:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.106 X-Spam-Level: X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=goessner.net Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85GFoDwNxeS3; Fri, 2 Feb 2024 05:27:37 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9364C1930B6; Fri, 2 Feb 2024 05:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=goessner.net; s=s1-ionos; t=1706880440; x=1707485240; i=stefan@goessner.net; bh=ZchDDgQtrBqb3Ng8Pe2gEZeCKa4Xwnu6D/HrAbAiupw=; h=X-UI-Sender-Class:Date:From:Subject:To:Cc:References: In-Reply-To; b=vJIHEF8lIQwVehKJzHOrEkFK917n6mNMrJ/M12CcDXIb6bfDI81Yua+hQJOiCuqJ Gi1II481OW1NrMD8xC/gG6xUb01KEz4pO8ZF9Vj9RuCC9XtFaAn+YXH94uHqXGoRp WmWjQrtu6p3IvwQfRTbB7581fsbjdQxdsf4qZxKoBPE3pKrFJFSo9LhWH6BOJbGqx I5b4jIBEKGP3pQNpgvYVnogCOw5g+QjWOeH+3ssW6jFp2BO5TmsJCzq38CfpgCKrk 0lsH9XyhY1Fws2omkaX9CDAd3tfxOfBaeXKb3j0apYuQKg00gV7+lYSuEP28eluBY QeoQiOQtCL++Z3dG4w== X-UI-Sender-Class: 55c96926-9e95-11ee-ae09-1f7a4046a0f6 Received: from [192.168.178.38] ([88.130.149.224]) by mrelayeu.kundenserver.de (mreue109 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MgNlB-1qpgrX2CdD-00hwWe; Fri, 02 Feb 2024 14:27:20 +0100 Content-Type: multipart/alternative; boundary="------------uDQh1UDRZVVXgqveC0DoJ0Jv" Message-ID: <8cfd8933-e0d8-4291-b1b5-de1550e0412d@goessner.net> Date: Fri, 2 Feb 2024 14:27:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: =?UTF-8?Q?Stefan_G=C3=B6ssner?= To: Carsten Bormann , Alanna Paloma Cc: RFC Errata System , glyn.normington@gmail.com, jsonpath-ads@ietf.org, jsonpath-chairs@ietf.org, Tim Bray , superuser@gmail.com, auth48archive@rfc-editor.org References: <20240130062410.D02DF1E64A@rfcpa.amsl.com> <8DDA3557-E82D-4A29-9AFA-DDD82BBA13B2@tzi.org> <5AB46EE0-BA9C-4C37-BA1E-FA47FD41EBEF@amsl.com> <40B5AA3A-D3FD-40C2-90F4-1992715B598F@tzi.org> In-Reply-To: <40B5AA3A-D3FD-40C2-90F4-1992715B598F@tzi.org> X-Provags-ID: V03:K1:Fx+8XkxgW3L33eZcHDzSLCncttv3GEB7GKYBdQsDJvFtnCvSpx1 fqMRzOj7X0NKzvFuOuAolCgGXmqmDCRh6lQUmwT5vJec9+yN1i421Vvs381v1V+0CJKxkxF PZdj3VKv4ccfjhczOEHTwFz3kS0iPuywZXUzxHY1tDJIh5yMNuPE6F00mXkCXM+X5HD+RM6 MVlOpfvK6t4TZ39La19Dg== UI-OutboundReport: notjunk:1;M01:P0:EexiJRy8hrs=;UXe4JDTlvlVX95TdcMA6OVv/ww0 uZeawJjYoYUAPjg5BA98ttIz2IcOKaEWdlqouKMmn55tMRU0YdjaAZSWCvRQmots3G0IjK+be fFUnDKfCQMdiuNylWZKeaiel/BZZBqwTXBMR8NnDmc1NJMzuMI2bk34BCZfi485EA1Tx0Kk1+ RpoHaGtIe8DqxcwVnzgezOQgHqRKQOVkkRxpvLWzc6LtGrhSOpiTafvD6OOGW5qW5yydmKm+X nWgsjF8TUyUsfBQNUYhl0Liogy0BbpbrrdeJtFkKzEwdDG+K2XL1Apkvsrtxy6ENg1vPV2krt sGsK+ekI8fGNLLlXOpYw82cmm/LMHsBCsGuJ+EaXTuywyn+Fbu8uh3Y+gBsf8/sWwQ02S4te8 mP8iw3ANc8rvij2YRAm7ndFyOAMIwXDg0B4MD5JqH3hYznq/v6GtRk+oj1RG9CpIiDZh6RQa+ Pj3fTmO7Znlychwa21FjZsWZ29XMqaDBt8abeSDKPMocff6zCak6qcBoMIOkTniQFjVVCuCTP seuHXdEK93u4gyQc5zfISFSpF6IsuN2ur9ovJfJvNtx0rNs5FslYR/sjSVa7ojLfIK4i5XFnA tTYo855+/5QiVcAkbRakUN6Bv3NXh70821m/LZdld6h4mr7bbAB4k6yLneTQCI7iYHjBKaSuQ JEIyvaF/iWiselp80606OJ9SJauBWf+RlmKAF1zNifpoE4RwQeIogpj1QpMbRigdmiBrEgfoN VhPgM4e3nkJYMZG13oQqj8m13mjhaxpxPzr/k6rWFzKVLHDg1XYmo0= Archived-At: Subject: Re: [auth48] AUTH48: RFC-to-be 9535 for your review X-BeenThere: auth48archive@rfc-editor.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2024 13:27:42 -0000 This is a multi-part message in MIME format. --------------uDQh1UDRZVVXgqveC0DoJ0Jv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I'm fine with anything here, except a single bit below ... Am 02.02.2024 um 13:50 schrieb Carsten Bormann: > Hi Alanna, > > thank you for the quick update. > For now, we=E2=80=99ll first respond specifically to your follow-up ques= tions/comments. > >> On 2024-02-02, at 02:41, Alanna Paloma wrote: >> >> Hi Carsten, >> >> Thank you for your replies. We have updated the document accordingly. P= lease note that we have a few follow-up questions/comments. >> >>>> 15) >>> This item is parallel to the one preceding it; this change loses this = useful structure. >> To clarify the text while maintaining the parallel structure, may we up= date with one of the suggestions listed below? >> >> Perhaps A: >> - numbers, where at least one is not expected to interoperate >> as per I-JSON, that compare equally using an >> implementation-specific equality, >> >> Perhaps B: >> - numbers, at least one of which is not expected to interoperate >> as per I-JSON, where the numbers compare equally using an >> implementation-specific equality, > =E2=80=9Ccompare equal=E2=80=9D is a term of art (compare with the resul= t that they are equal), compare equally does not quite make sense in this = context. > So the change reduces to adding a comma, which probably can be done, eve= n if strictly speaking this changes the relative clause to a non-defining = one when a defining one is actually meant (this will be clear from the con= text). > > NEW: > - numbers, at least one of which is not expected to interoperate > as per I-JSON, where the numbers compare equal using an > implementation-specific equality, > >>>> 21) >>> This needs a =E2=80=9Crespectively=E2=80=9D. The dot syntax is lightw= eight, but limited, while the bracket syntax is more heavyweight. >> We have updated the text per your suggestion. >> >> Current: >> JSONPath expressions move further down the hierarchy using _dot >> notation_ ($.store.book[0].title) or the _bracket notation_ >> ($['store']['book'][0]['title']), a lightweight/limited syntax >> and a more heavyweight syntax, respectively, replacing XPath's / >> within query expressions. >> >> However, to improve readability, may the sentence be further updated as= follows? >> >> Perhaps: >> JSONPath expressions move further down the hierarchy using _dot >> notation_ ($.store.book[0].title) or the _bracket notation_ >> ($['store']['book'][0]['title=E2=80=99]); both replace XPath's / with= in query expressions, >> but _dot notation_ is a lightweight/limited syntax while _bracket not= ation_ >> is a more heavyweight syntax. > I don=E2=80=99t see a need for a =E2=80=9Cbut=E2=80=9D for the whole sub= clause, but could use one for the slash, so maybe: > > Suggestion: > JSONPath expressions move further down the hierarchy using _dot > notation_ ($.store.book[0].title) or the _bracket notation_ > ($['store']['book'][0]['title=E2=80=99]); both replace XPath's / withi= n query expressions, > where _dot notation_ serves as a lightweight but limited syntax while = _bracket notation_ > is a more heavyweight syntax. Suggestion: ... where _dot notation_ serves as a lightweight but limited syntax while = _bracket notation_ is a more heavyweight but unlimited (general) syntax. >>>> 23) >>> One of us believes the sourcecode-type should be application/jsonpath. >>> But as long as we don=E2=80=99t use media-type names, we probably shou= ld shorten this to jsonpath. >>> (=C2=A7 3.1 does not suggest a filename extension, which would be a na= tural candidate. JSONPath is uncharacteristically mixed case, and =E2=80= =9Cjsonpath=E2=80=9D (lower case) is closest to what has been done to othe= r sourcecode-types.) >> We have sent a request to the RFC Production Advisory Team (RPAT) about= adding =E2=80=9Cjsonpath" to the list of preferred values. See. >> >> For now, we have updated to use type=3D=E2=80=9Cjsonpath=E2=80=9D and w= ill update further depending on the outcome of the RPAT discussion. > Good, thank you! > > One more observation: > >>> Given that we no longer have good information about this example, we t= hink we can simplify this to: >>> >>>> The books example was taken from course material that University Biel= efeld, Germany used in 2002. > I looked uphttps://www.uni-bielefeld.de/ only now, and I notice that th= e university styles itself =E2=80=9CBielefeld University=E2=80=9D in Engli= sh, which we should follow (the German name is =E2=80=9CUniversit=C3=A4t B= ielefeld=E2=80=9D, which led to my mistake). > > Gr=C3=BC=C3=9Fe, Carsten --------------uDQh1UDRZVVXgqveC0DoJ0Jv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
I'm fine with anything here, except a single bit below ...

Am 02.02.2024 um 13:50 schrieb Carsten Bormann: 
Hi Alanna,

thank you for the quick update.
For now, we=E2=80=99ll first respond specifically to your follow-up questi=
ons/comments.


On 2024-02-02, at 02:41, Al=
anna Paloma <apaloma@amsl.com> wrote:

Hi Carsten,

Thank you for your replies. We have updated the document accordingly. Plea=
se note that we have a few follow-up questions/comments.


15) <!--[rfced] For =
clarity, may we update this list item as follows?

Original:
-  numbers at least one of which is not expected to interoperate
 as per I-JSON, where the numbers compare equal using an
 implementation specific equality,

Perhaps:
-  numbers that compare equally using an implementation-specific
 equality, where at least one is not expected to
 interoperate as per I-JSON,
=2D->

This item is parallel to =
the one preceding it; this change loses this useful structure.

To clarify the text while m=
aintaining the parallel structure, may we update with one of the suggestio=
ns listed below?

Perhaps A:
    -  numbers, where at least one is not expected to interoperate
       as per I-JSON, that compare equally using an
       implementation-specific equality,

Perhaps B:
    -  numbers, at least one of which is not expected to interoperate
       as per I-JSON, where the numbers compare equally using an
       implementation-specific equality,

=E2=80=9Ccompare equal=E2=80=
=9D is a term of art (compare with the result that they are equal), compar=
e equally does not quite make sense in this context.
So the change reduces to adding a comma, which probably can be done, even =
if strictly speaking this changes the relative clause to a non-defining on=
e when a defining one is actually meant (this will be clear from the conte=
xt).

NEW:
    -  numbers, at least one of which is not expected to interoperate
       as per I-JSON, where the numbers compare equal using an
       implementation-specific equality,


21) <!-- [rfced] Ple=
ase review "a lightweight/limited, and a more heavyweight
syntax". Is the syntax both lightweight and heavyweight? Or is another
meaning intended?

Original:
JSONPath expressions move further down the hierarchy using _dot
notation_ ($.store.book[0].title) or the _bracket notation_
($['store']['book'][0]['title']), a lightweight/limited, and a more
heavyweight syntax replacing XPath's / within query expressions.
=2D->

This needs a =E2=80=9Cres=
pectively=E2=80=9D.  The dot syntax is lightweight, but limited, while the=
 bracket syntax is more heavyweight.

We have updated the text pe=
r your suggestion.

Current:
 JSONPath expressions move further down the hierarchy using _dot
 notation_ ($.store.book[0].title) or the _bracket notation_
 ($['store']['book'][0]['title']), a lightweight/limited syntax
 and a more heavyweight syntax, respectively, replacing XPath's /
 within query expressions.

However, to improve readability, may the sentence be further updated as fo=
llows?

Perhaps:
 JSONPath expressions move further down the hierarchy using _dot
 notation_ ($.store.book[0].title) or the _bracket notation_
 ($['store']['book'][0]['title=E2=80=99]); both replace XPath's / within q=
uery expressions,
 but _dot notation_ is a lightweight/limited syntax while _bracket notatio=
n_
 is a more heavyweight syntax.

I don=E2=80=99t see a need fo=
r a =E2=80=9Cbut=E2=80=9D for the whole subclause, but could use one for t=
he slash, so maybe:

Suggestion:
 JSONPath expressions move further down the hierarchy using _dot
 notation_ ($.store.book[0].title) or the _bracket notation_
 ($['store']['book'][0]['title=E2=80=99]); both replace XPath's / within q=
uery expressions,
 where _dot notation_ serves as a lightweight but limited syntax while _br=
acket notation_
 is a more heavyweight syntax.

Suggestion:

... where _dot notation_ serves as a lightweight but limited syntax while =
_bracket notation_
 is a more heavyweight but unlimited (general) syntax.


23) <!-- [rfced] We =
see type=3D"JSONPath" is used for some of the sourcecode elements
in this document. This is not included in our current list of preferred
values; see https://www.rfc-editor.org/materials/=
sourcecode-types.txt.
Please review the list and let us know which value to use for "type".

If the current list does not contain an applicable type, feel free to sugg=
est
additions for consideration. Note that it is also acceptable to leave the
"type" attribute not set.
=2D->

One of us believes the so=
urcecode-type should be application/jsonpath.
But as long as we don=E2=80=99t use media-type names, we probably should s=
horten this to jsonpath.
(=C2=A7 3.1 does not suggest a filename extension, which would be a natura=
l candidate.  JSONPath is uncharacteristically mixed case, and =E2=80=9Cjs=
onpath=E2=80=9D (lower case) is closest to what has been done to other sou=
rcecode-types.)

We have sent a request to t=
he RFC Production Advisory Team (RPAT) about adding =E2=80=9Cjsonpath" to =
the list of preferred values. See <https://mailarchive.ietf.org/arch/msg=
/rpat/vVTLmBBHHMnL_tLf-p-QbwEHyHM/>.

For now, we have updated to use type=3D=E2=80=9Cjsonpath=E2=80=9D and will=
 update further depending on the outcome of the RPAT discussion.

Good, thank you!

One more observation:


Given that we no longer h=
ave good information about this example, we think we can simplify this to:


The books example was t=
aken from course material that University Bielefeld, Germany used in 2002.

I looked up https://www.uni-bielefeld.de/ only now,=
 and I notice that the university styles itself =E2=80=9CBielefeld Univers=
ity=E2=80=9D in English, which we should follow (the German name is =E2=80=
=9CUniversit=C3=A4t Bielefeld=E2=80=9D, which led to my mistake).

Gr=C3=BC=C3=9Fe, Carsten

--------------uDQh1UDRZVVXgqveC0DoJ0Jv--