Subject: Re: [regext] FW: I-D Action: draft-hollenbeck-regext-rfc7482bis-00.txt

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 03:06:24 -0500

On Thu, Jan 23, 2020, at 07:35, Hollenbeck, Scott wrote:
> FYI, folks. I just submitted the first version of 7482bis. I've 
> addressed the known errata, but I also have some clarification 
> suggestions queued up for discussion. I'll start a thread for each of 
> those shortly.

See my previous email on RFC7483bis the same caveat (on the breadth of changes called for) applies here.

3.1.3

This part comes directly from direct observations of what exists out there.
There is at least one RDAP server that generates URL for the "next" RDAP server
(to query the registrar) with the domain name in full uppercase.
For ASCII domains, this makes no difference.
However, I have seen multiple registrar RDAP servers that then fail to process
this URL. Just changing the domain name in the URL from uppercase to lowercase
makes the registrar RDAP server work.

One can say that this second server is broken, but another can say that lowercase
should be preferred, because if the name is in U-label form, you do not uppercase
it anyway, you leave it as is.

So while maybe we could keep accepting as input when doing the query
the name in any mixed case, maybe server should be expected to generate URLs 
in specific letter case?

RFC5890 says:
Therefore, since a valid A-label is the result of
   Punycode encoding of a U-label, A-labels should be produced only in
   lowercase, despite matching other (mixed-case or uppercase) potential
   labels in the DNS.

So maybe rfc7482bis should give more guidance either explicitly allowing
both forms, or mandating only one, etc.

Of course, potentially, same applies for 3.1.4 and 3.2.*

5. Extensibility

See my discussion about the prefix for attributes and the rdapConformance token
name in the thread on 7483bis
But same here for path elements, do we want the prefix to have any relationship
with the token in rdapConformance?

9.2 Nitpick

Use https:// for
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Also in general for all bis drafts, and please excuse my ignorance there, but
shouldn't they reference themselves on the bis version instead of previous one?
Example, this text:
"   This document does not describe the results or entities returned from
   issuing the described URLs with an HTTP GET.  The specification of
   these entities is described in [RFC7483].

"

Shouldn't RFC7483 be replaced by the draft rfc7483bis?

PS: there is currently a problem in the tracker,
on https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rfc7482bis/
a version 03 is shown as existing but you can't view the content.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 27 Apr 2020 11:27:28 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Monday, April 27, 2020 4:06 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext-
> rfc7482bis-00.txt
>
>
>

The goal of the update is to only address necessary editorial corrections and clarifications. No protocol changes. Some of what you describe below has already come up in on-list discussion, so it will be addressed. Anything that changes the protocol itself will be out of scope for now. I'll take a look at everything below as I work on the next version of the document.

Scott

> There is at least one RDAP server that generates URL for the "next" RDAP
> server (to query the registrar) with the domain name in full uppercase.
> However, I have seen multiple registrar RDAP servers that then fail to
> process this URL. Just changing the domain name in the URL from uppercase
> to lowercase makes the registrar RDAP server work.
>
> One can say that this second server is broken, but another can say that
> lowercase should be preferred, because if the name is in U-label form, you
> do not uppercase it anyway, you leave it as is.
>
> So while maybe we could keep accepting as input when doing the query the
> name in any mixed case, maybe server should be expected to generate URLs
> in specific letter case?
>
> RFC5890 says:
> See my discussion about the prefix for attributes and the rdapConformance
> token name in the thread on 7483bis But same here for path elements, do
> we want the prefix to have any relationship with the token in
> rdapConformance?
>
>
> 9.2 Nitpick
>
> Use https:// for
> http://secure-web.cisco.com/1nISAjXBpKL_XIglWvOW0Z69bNYuU7P-
> Vyn7KAwEKh9j-ac54KiLWzTR-krTSDR34ISI1-
> 8aDLHBYBILKyhQ_rg4aBDSDwDNMrP2Pj3n85oemJCDRCXjTJIu_WkYQ7EPA58
> sdEGR_5MYw9HaS4JSHuOKOm4uxA1tN8BZEtnVJCF0XeVbKl8S3D_oaeIfc6zZF
> dwIi3UGRWbxscxTIJKU-
> tADzhfDXPjZmzLVfUCGr42xabBKvi_Ti1Nd0FGNEgY9nb2NM66SWeQhzdzpsn
> 9jP3g/http%3A%2F%2Fwww.ics.uci.edu%2F%7Efielding%2Fpubs%2Fdisserta
> tion%2Ffielding_dissertation.pdf
>
>
>
> PS: there is currently a problem in the tracker, on https://secure-
> web.cisco.com/1YVDVzKtTJoaVCJqtJ6jmMmAyc385Fif2d0IPdsKbQacOIRJ9tz
> wxVPM6iHxe-
> tME45ThxCqPMpgqvLRESYsoLO3EPcEviZXznuxJ_7_F14IVxBgXNS1JbXBLbNcp
> URZbAUr0D2NmfBDZ3AhFzawHjlF8HL6CxP1iuoUpcjNzRrMJTEJMoZnRpwSFH
> FMpWoxmdC25G1L8pCcubvIP7zhGiuKgY0rZ3CrNwmWPJLy1oi99AMhSz3aC7
> psPsGBli8Zixvi-_Sj4rWIN-
> bL82fITwA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-
> hollenbeck-regext-rfc7482bis%2F
> _______________________________________________
> regext mailing list
> [email-masked]
> https://secure-
> web.cisco.com/1DY9WMBrzyv3laxynA6_cYd9taMoltKCnLtBssrQ3LkYLY34xiaN
> 20C1lsyFPpmUQM6oE_hVZ9gcfkcX2EhcQM32LAwg-
> P_jbeEko9rfuq5jnPrl1Qf5UhlDq9STZfkyaGfuiC9v4Np1U8uKraQELXsCDtWQ8g
> LugjA7oufnVO83PSagt6biGxX2HDkGcGuqcvlSmc8rFHpiBnQB0KisFp8UPGWm
> HgeqfP2pmuluLNTFmNrPHJVEPI9QFbW1OeCEnLkFIHxvM71CcB6dlRt-
> fHUL4286eH9fVSAZ-
> 4QUeyLs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 27 Apr 2020 10:47:24 -0500

On Mon, Apr 27, 2020, at 06:27, Hollenbeck, Scott wrote:
> The goal of the update is to only address necessary editorial 
> corrections and clarifications. No protocol changes. Some of what you 
> describe below has already come up in on-list discussion, so it will be 
> addressed. Anything that changes the protocol itself will be out of 
> scope for now. I'll take a look at everything below as I work on the 
> next version of the document.

Thanks Scott for your explanation and hence sorry for my two emails.

There may be a few things and nitpicks that could still be viewed as "corrections
and clarifications" and hence be useful, but indeed some other points are really
like protocol enhancements (based on what I see on the field today, trying to use
RDAP servers in gTLDs right now is really a minefield...) and hence sadly will
need to be jettisoned for now.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 27 Apr 2020 16:36:26 +0000

> Sent: Monday, April 27, 2020 11:47 AM
> To: [email-masked]
> > > Subject: [EXTERNAL] Re: [regext] FW: I-D Action:
> > > draft-hollenbeck-regext- rfc7482bis-00.txt
> > >
> > >
> > >
> > > > suggestions queued up for discussion. I'll start a thread for each
> > > > of those shortly.
> > >
> > >
> > describe below has already come up in on-list discussion, so it will
> > be addressed. Anything that changes the protocol itself will be out of
> There may be a few things and nitpicks that could still be viewed as
> "corrections and clarifications" and hence be useful, but indeed some other
> points are really like protocol enhancements (based on what I see on the
> field today, trying to use RDAP servers in gTLDs right now is really a
> minefield...) and hence sadly will need to be jettisoned for now.

Let's not jettison the issues. We should capture them in a place like the WG wiki and queue them up for discussion if we ever get around to talking about RDAP 1.1 or 2.0. I'll take that on as an action as I triage the feedback I'm getting for 7482bis and 7483bis.

Scott