Re: [regext] AD review of draft-ietf-regext-rdap-sorting-and-paging-14

Barry Leiba <> Tue, 28 July 2020 13:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AA543A0C13; Tue, 28 Jul 2020 06:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HSxZpll56tmp; Tue, 28 Jul 2020 06:11:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2DE93A0C10; Tue, 28 Jul 2020 06:11:43 -0700 (PDT)
Received: by with SMTP id s21so16076109ilk.5; Tue, 28 Jul 2020 06:11:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+YM6HyE3N4l2HIiefwzKcg6lQ+Tdob/URbi4zVK17Qc=; b=aKys53Vl4FMfRMCoMdTdk08BjFrlUzF5mP/rJdruKQBEmNYxfkvu/K8wEHxAljV7u1 fmbJNcjmRfgYypGiKeTg7lx9XkGPa1Fkgva5EEOo2pAJMD3f1EBwU/fEKafIklo/R7Tn CZOsmT7ULiTHikppBX+tpTET9dVKSVT/R4tsqb1ChrhAo/2cGW2dcsPtRsPJepZTuxyf Sa54DLwbEd0qHdHoIcVrFMYIY58GMuS1rrZ8KYa5htG9cFbcBuwvsC5IywF8m5gGTcxl sZN9A3DZG54YG10kDz9TYLI/tD7QFwtCnS4jCHY9a2s4oo4XrNbqNzCOMDUuiyxlV0wh ieIg==
X-Gm-Message-State: AOAM531G9ViwX/D6taeXs/2hvjtCvuRnkUTiXyAJMqxE0gPv6fQ7rwjD rOccYO+MxKBJ0MTqkkOVE7/Qnm79m2CVuVjZkqooMO+i
X-Google-Smtp-Source: ABdhPJwWtqykvo0g95MMdkb0ds+qtSI0g+rODSg4u+/ILyG0KHmpo6NtOlX1uRAbmh5I4eOoXTPLt8y72xfpyPkT+lU=
X-Received: by 2002:a05:6e02:8a8:: with SMTP id a8mr29676383ilt.52.1595941902540; Tue, 28 Jul 2020 06:11:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Barry Leiba <>
Date: Tue, 28 Jul 2020 09:11:31 -0400
Message-ID: <>
To: Mario Loffredo <>
Cc: "" <>, regext <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [regext] AD review of draft-ietf-regext-rdap-sorting-and-paging-14
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: Tue, 28 Jul 2020 13:11:46 -0000

Hi, Mario; thanks for the response.  I've eliminated, below, the
comments that I consider addressed.

>    o  "totalCount": "Numeric" (OPTIONAL) a numeric value representing
>       the total number of objects found.  It MUST be provided if the
>       query string contains the "count" parameter;
> Section 2.2 says also that it MUST NOT be provided otherwise, and I
> suggest adding that here as well: ‘It MUST be provided if the query
> string contains the "count" parameter, and MUST NOT be provided
> otherwise;’, or perhaps ‘It MUST be provided if and only if the query
> string contains the "count" parameter;’.  I also wonder whether the
> same thing is true for pageSize and pageNumber.
> [ML] Opted for "if and only if". The same doen't work for for pageSize
> and pageNumber because thy are provided depending on the comparison
> between the maximum number of results returned in a  page and the total
> number of objects found.

Right, but I think you misunderstood what I meant by "the same".
Clearly, pageSize and pageNumber aren't controlled by the "count"
parameter.  What I meant was whether it's also true that pageSize and
pageNumber are also provided on an "if and only if" basis: if and only
if the total number of objects found exceeds the page size.

>       This property is redundant for clients because the page size can
>       be derived from the length of the search results array but it can
>       be helpful if the end user interacts with the server through a web
>       browser;
> But a web browser is a client too.  I suggest “redundant for some clients”; what do you think?
> [ML] I propose "RDAP clients". Is it okay?

It's kind of okay, but... when a web browser is doing RDAP, isn't it
also an RDAP client?  I think what you're really referring to is
purpose-built RDAP clients, which will likely have been coded to more
completely understand the full RDAP.  I'm not sure what the best way
to refer to those is, and calling them "RDAP clients" might be fine,
and the right answer.  I think people will understand what you mean.
Let's go with that, and see if there are any comments about it during
last call or from the IESG.  I think it will be okay.