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

["Hollenbeck, Scott" <[e-mail]>]

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

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

> 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://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
>
>
>
> 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://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
> a version 03 is shown as existing but you can't view the content.
>
>
> --
>   Patrick Mevzek
>   [e-mail]
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://secure-
> web.cisco.com/1DY9WMBrzyv3laxynA6_cYd9taMoltKCnLtBssrQ3LkYLY34xiaN
> 20C1lsyFPpmUQM6oE_hVZ9gcfkcX2EhcQM32LAwg-
> P_jbeEko9rfuq5jnPrl1Qf5UhlDq9STZfkyaGfuiC9v4Np1U8uKraQELXsCDtWQ8g
> LugjA7oufnVO83PSagt6biGxX2HDkGcGuqcvlSmc8rFHpiBnQB0KisFp8UPGWm
> HgeqfP2pmuluLNTFmNrPHJVEPI9QFbW1OeCEnLkFIHxvM71CcB6dlRt-
> fHUL4286eH9fVSAZ-
> 4QUeyLs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext