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

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

Sorry, Patrick, I missed these comments. I'll look at them in more detail tomorrow.

Scott

> -----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.
>
> 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