Sorry, Patrick, I missed these comments. I'll look at them in more detail tomorrow.
Scott > -----Original Message----- > From: regext <[email protected]> On Behalf Of Patrick Mevzek > Sent: Monday, April 27, 2020 4:06 AM > To: [email protected] > 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. > > 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 > [email protected] > > _______________________________________________ > regext mailing list > [email protected] > https://secure- > web.cisco.com/1DY9WMBrzyv3laxynA6_cYd9taMoltKCnLtBssrQ3LkYLY34xiaN > 20C1lsyFPpmUQM6oE_hVZ9gcfkcX2EhcQM32LAwg- > P_jbeEko9rfuq5jnPrl1Qf5UhlDq9STZfkyaGfuiC9v4Np1U8uKraQELXsCDtWQ8g > LugjA7oufnVO83PSagt6biGxX2HDkGcGuqcvlSmc8rFHpiBnQB0KisFp8UPGWm > HgeqfP2pmuluLNTFmNrPHJVEPI9QFbW1OeCEnLkFIHxvM71CcB6dlRt- > fHUL4286eH9fVSAZ- > 4QUeyLs/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
