Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-rdap-sorting-and-paging-17: (with COMMENT)

Mario Loffredo <> Sat, 26 September 2020 14:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23FD93A0A27; Sat, 26 Sep 2020 07:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2XIIEIg3ERk; Sat, 26 Sep 2020 07:41:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C92D13A09FD; Sat, 26 Sep 2020 07:41:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0394860069F; Sat, 26 Sep 2020 16:41:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hDh-rhqDPT9t; Sat, 26 Sep 2020 16:41:22 +0200 (CEST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 07473600252; Sat, 26 Sep 2020 16:41:22 +0200 (CEST)
To: Murray Kucherawy <>, The IESG <>
Cc:,,, Tom Harrison <>
References: <>
From: Mario Loffredo <>
Message-ID: <>
Date: Sat, 26 Sep 2020 16:38:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: it
Archived-At: <>
Subject: Re: [regext] Murray Kucherawy's No Objection on draft-ietf-regext-rdap-sorting-and-paging-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Sep 2020 14:41:30 -0000

Hi Murray,

thanks a lot for your review. Please find my comments inline.

Il 24/09/2020 09:57, Murray Kucherawy via Datatracker ha scritto:
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-regext-rdap-sorting-and-paging-17: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I support Roman's DISCUSS point about resolving the JSONPath reference.  I'm
> working the chartering of the proposed "jsonpath" working group, so I'm happy
> to contribute to resolving this.  And a "thank you" to the document shepherd
> for including this in the writeup.  Another possible option is to cite
> draft-goessner-dispatch-jsonpath, marking it as "work in progress", though I
> think that's still tricky because we don't know for sure that changes produced
> by the proposed working group will be fully backward-compatible with what this
> document requires.
> I also support Ben's DISCUSS point about multi-sorts.

[ML] As it is stated in the draft of JSONPath WG Charter 
(, the 
primary goal implementation is capturing the common semantics of 
existing implementations. The JSONPath operators used in this document 
are absolutely basic so I'm confident that this specification will be 
fully compliant with the WG outcomes. I believe that the future JSONPath 
specification will contain something more rather than something less 
with respect to this document.

draft-goessner-dispatch-jsonpath couldn't be the reference draft so I'm 
a bit doubtful about citing it.

> Section 1:
> A totally minor nit, but I think the reference to RFC 7230 should be up where
> HTTP is first used.
[ML] OK. Maybe it could be more appropriate to insert the reference to 
RFC 7231 that contains a section about the definition on new header fields.
> Section 2.2:
> The ABNF here reminds me that string literals in ABNF are case-insensitive (RFC
> 5234, Section 2.3).  Just wanted to check that "COUNT=fAlSe" is fine here, for
> example.
[ML] AFAIK, REST API libraries convert the cited strings into boolean 
values regardless they are written so  I wouldn't change anything.

Looking forward for your reply to my comments.



Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240