Re: [auth48] AUTH48: RFC-to-be 9485 <draft-ietf-jsonpath-iregexp-08> for your review

[Carsten Bormann <[e-mail]>]

Dear RFC Editor,

Carsten is now back from his keyboardless Albania vacation — apologies for the one-week reaction time.
Here are the authors' responses to the questions.

> On 2023-09-13, at 22:50, [e-mail] wrote:
> 
> Authors,
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Please note that the title of the document has been
>    updated as follows:
> 
> Original:
> I-Regexp: An Interoperable Regexp Format
> 
> Current:
> I-Regexp: An Interoperable Regular Expression Format
> -->
> 

This indeed works, because “regexp” stays searchable as it is part of I-Regexp.
Thank you!

> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>    the title) for use on https://www.rfc-editor.org/search. -->
> 

Considering the previous change, please add:

Regexp
Regex

> 3) <!--[rfced] We see citations corresponding to PCRE and RE2, but no
>    citation has been included for the Ruby programming language.
>    Should something be added here?
> 
> Original:
> 5.4.  PCRE, RE2, Ruby Regexps
> 
>  Perform the same steps as in Section 5.3 to obtain a valid regexp in
>  PCRE [PCRE2], the Go programming language [RE2], and the Ruby
>  programming language, except that the last step is:
> 
> 
> -->
> 

We don’t think we need to provide a reference to the Ruby programming language. But we think we should change the text slightly to say 

OLD:
the Go programming language <xref target="RE2"/>
NEW:
the Go programming language's RE2 regexp library <xref target="RE2"/>

> 4) <!--[rfced] Note that we often see a "Motivation and Background" type
>    of section near to (or as a subsection of) the
>    Introduction. Please review if text movement makes sense. -->

We actually had similar discussions before; we prefer it the way it is.

> 5) <!--[rfced] The following sentence might be easier for the reader if
>    broken up both visually and across sentences.  To ensure that we
>    have maintained your meaning, please consider the points
>    following the sentence and our suggested text after that:
> 
> Original:
> Specifically, range quantifiers (as in a{2,4}) provide particular
> challenges for both existing and I-Regexp focused implementations.
> These may therefore limit range quantifiers in composability
> (disallowing nested range quantifiers such as (a{2,4}){2,4}) or range
> (disallowing very large ranges such as a{20,200000}), or detect and
> reject any excessive resource consumption caused by them.
> 
> a) How many items are in the list of what "these" may do?

Suggestion for the “These”:

OLD:
These may therefore limit
NEW:
Implementations may therefore limit

> Specifically, how does the very last clause relate to the rest of the
> text?  Might a bulleted list make this text visually easier to
> understand?
> 
> b) Will the reader easily know what "these" and "them" are referring
> to?

As you are proposing below:

OLD:
caused by them
NEW:
caused by range quantifiers

> c) Are the implementations both existing AND I-Regexp or are you
> referring to both existing implementations and I-Regexp focused
> implementations?

The latter.
We don’t think there’s a problem here, we’re discussing implementations in general; which might be new or might be based on existing implementations.

> Perhaps:
> Specifically, range quantifiers (as in a{2,4}) provide particular
> challenges for both existing implementations and those that are
> I-Regexp focused.  Therefore, these implementations may:
> 
> *limit range quantifiers in composability (disallowing nested range
> quantifiers such as (a{2,4}){2,4}),
> 
> *limit range quantifiers in range (disallowing very large ranges such
> as a{20,200000}), or
> 
> *detect and reject any excessive resource consumption caused by range
> quantifiers.-->

The bullet list could be read as an alternative with three choices, when really this is a selection of mitigations which make sense in various combinations.  We don’t really want to provide detailed implementation advice on which combinations would work in which kinds of implementations; with the active research in this space that would be too short-lived.

> 6) <!--[rfced] Note that there were a few instances in which we updated
>    lists to appear in bulleted format for the ease of the reader.
>    Please review to ensure we've maintained your intended meaning
>    and let us know any objections.-->

While we haven’t completed the full re-read, we have reviewed the bullet lists and the new ones indeed appear to improvements.

> 7) <!-- [rfced] Since the provided title for reference [RE2] is taken
>    from the "About" section of the provided URL and is rather long,
>    we wanted to verify that this is the desired title or if another
>    title is known.  Please let us know how/if we may update.
> 
> Current:
>  [RE2]      "RE2 is a fast, safe, thread-friendly alternative to
>             backtracking regular expression engines like those used in
>             PCRE, Perl, and Python. It is a C++ library.", commit
>             73031bb, <https://github.com/google/re2>.
> -->

Indeed.  We need to find a way to both be true to the cited reference and be useful in this document.  There is nothing on this page that could serve as an actual title, so there is no “correct” solution.  We believe that using the “About” text as a title is not too jarring, actually quite useful and is compatible with the way we need to reference github resources.

> 8) <!-- [rfced] Please review the "type" attribute of the sourcecode element 
> in the XML file to ensure correctness. If the current list of preferred values 
> for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt) does not 
> contain an applicable type, then feel free to let us know. Also, it is acceptable 
> to leave the "type" attribute not
> set.  
> -->

type=“abnf” was deliberately chosen and is the correct sourcecode type.

> 9) <!-- [rfced] Please review whether any of the notes in this document
> should be in the <aside> element. It is defined as "a container for 
> content that is semantically less important or tangential to the 
> content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside)
> .
> -->

The authors are well aware of the <aside element and haven’t seen a need to use it here.  (We’ll keep this question in mind during the full reread.)

> 10) <!-- [rfced] Please review the use of <tt> and <em> throughout the
>    document:
> 
> In the html and pdf outputs, the text enclosed in <tt> is output in
> fixed-width font. In the txt output, there are no changes to the font,
> and the quotation marks have been removed.
> 
> In the html and pdf outputs, the text enclosed in <em> is output in
> italics. In the txt output, the text enclosed in <em> appears with an
> underscore before and after.
> 
> Please review carefully and let us know if the output is acceptable or
> if any updates are needed.
> -->

The usage of <tt was deliberate and appears correct as intended.
(RFCXML currently does not provide a way to do the semantic markup that might be used instead, as in <code, <var, <kbd in HTML …)

The single use of <em around "checking” is somewhat more bothersome. It is the first appearance of a defined term that is then used repeatedly in the following text. It should be visually distinguished, but in the HTML world <em has very explicit semantics, "emphasis", which isn’t what is happening here (we might be using <i in HTML).  Also, the current TXT fallback representation of this distinction can be confusing.

This might be an example where it could help to develop a general style, even an RFC Editor standard approach, for introducing new terms which are being defined.  
But as long as that hasn’t happened, no change is needed here now.


> 11) <!-- [rfced] Please review the "Inclusive Language" portion of the
>    online Style Guide
>    <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>    and let us know if any changes are needed.
> 
> -->

No such changes appear to be needed.
(We’ll keep this question in mind as well during the full reread.)

Thank you!

Carsten and Tim


> 
> 
> Thank you.
> 
> RFC Editor/kf/mf
> 
> 
> *****IMPORTANT*****
> 
> Updated 2023/09/13
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.  
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review 
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>  Please review and resolve any questions raised by the RFC Editor 
>  that have been included in the XML file as comments marked as 
>  follows:
> 
>  <!-- [rfced] ... -->
> 
>  These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors 
> 
>  Please ensure that you review any changes submitted by your 
>  coauthors.  We assume that if you do not speak up that you 
>  agree to changes submitted by your coauthors.
> 
> *  Content 
> 
>  Please review the full content of the document, as this cannot 
>  change once the RFC is published.  Please pay particular attention to:
>  - IANA considerations updates (if applicable)
>  - contact information
>  - references
> 
> *  Copyright notices and legends
> 
>  Please review the copyright notice and legends as defined in
>  RFC 5378 and the Trust Legal Provisions 
>  (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>  Please review the markup in the XML file to ensure that elements of  
>  content are correctly tagged.  For example, ensure that <sourcecode> 
>  and <artwork> are set correctly.  See details at 
>  <https://authors.ietf.org/rfcxml-vocabulary>.
> 
> *  Formatted output
> 
>  Please review the PDF, HTML, and TXT files to ensure that the 
>  formatted output, as generated from the markup in the XML file, is 
>  reasonable.  Please note that the TXT will have formatting 
>  limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all 
> the parties CCed on this message need to see your changes. The parties 
> include:
> 
>  *  your coauthors
> 
>  *  [e-mail] (the RPC team)
> 
>  *  other document participants, depending on the stream (e.g., 
>     IETF Stream participants are your working group chairs, the 
>     responsible ADs, and the document shepherd).
> 
>  *  [e-mail], which is a new archival mailing list 
>     to preserve AUTH48 conversations; it is not an active discussion 
>     list:
> 
>    *  More info:
>       https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
> 
>    *  The archive itself:
>       https://mailarchive.ietf.org/arch/browse/auth48archive/
> 
>    *  Note: If only absolutely necessary, you may temporarily opt out 
>       of the archiving of messages (e.g., to discuss a sensitive matter).
>       If needed, please add a note at the top of the message that you 
>       have dropped the address. When the discussion is concluded, 
>       [e-mail] will be re-added to the CC list and 
>       its addition will be noted at the top of the message. 
> 
> You may submit your changes in one of two ways:
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text, 
> and technical changes.  Information about stream managers can be found in 
> the FAQ.  Editorial changes do not require approval from a stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> Files 
> -----
> 
> The files are available here:
>  https://www.rfc-editor.org/authors/rfc9485.xml
>  https://www.rfc-editor.org/authors/rfc9485.html
>  https://www.rfc-editor.org/authors/rfc9485.pdf
>  https://www.rfc-editor.org/authors/rfc9485.txt
> 
> Diff file of the text:
>  https://www.rfc-editor.org/authors/rfc9485-diff.html
>  https://www.rfc-editor.org/authors/rfc9485-rfcdiff.html (side by side)
> 
> Diff of the XML: 
>  https://www.rfc-editor.org/authors/rfc9485-xmldiff1.html
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>  https://www.rfc-editor.org/auth48/rfc9485
> 
> Please let us know if you have any questions.  
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC9485 (draft-ietf-jsonpath-iregexp-08)
> 
> Title            : I-Regexp: An Interoperable Regexp Format
> Author(s)        : C. Bormann, T. Bray
> WG Chair(s)      : James Gruessing, Tim Bray
> Area Director(s) : Murray Kucherawy, Francesca Palombini