> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Patrick Mevzek > Sent: Monday, April 27, 2020 3:51 AM > To: regext@ietf.org > Subject: [EXTERNAL] Re: [regext] FW: I-D Action: draft-hollenbeck-regext- > rfc7483bis-00.txt > > Hello Scott, > > On Tue, Feb 18, 2020, at 07:31, Hollenbeck, Scott wrote: > > Lastly, let's > > start to talk about any other needed clarifications. Are you aware of > > any? Send 'em to the list for discussion. > > First, please excuse me in advance if I didn't understood things right, as my > points below are maybe more than a clarification so I do not know if the bis > version is expected just to fix the nitpicks/errata or really revisit some > points. > > If the latter feel free to disregard most of the below. They are in part > related > to previous discussions here and also Marc's draft on deployment findings.
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 > 2.1 > I think there should be far more explanations (or even enforcement) of the > relationship, if any, from the specific label used in rdapConformance and > then used as prefix for extended names. > > Like, to be able to use "lunarNic_beforeOneSmallStep" and > "lunarNic_harshMistressNotes" > does that mean that there should be (and hence registered at IANA) > "lunarNic_level_0" in rdapConformance? > This seems to be the case, comparing text between 2.1 and 4, but I think it > should be more stressed out if it is a requirement. > > There should be more explanation also on what is registered at IANA, since > there is confusion, about the "level_0" ending. Is that mandatory? > Suggested? > > > 4.2 Links > > I think there should be more explanation of what "value" (the context URI) > means in the case of RDAP. It is optional like all others except href, but is > visible in examples, so more guidance would be welcome. > > 4.8 publicIDs > > I am under the impression that the same structure as for links could be > reused. > Also "type" should be better explained or even be in a IANA registry. > > Unfortunately I lost my previous notes but I think I sensed there a possible > interoperability problem, but now I am not so sure. Sorry about that, will try > to remember that point again. > > 5.2 Maybe nitpick > > "ldhName" : "ns1.xn--fo-5ja.example", > "unicodeName" : "ns1.foo.example", > > It is absolutely not clear that the unicodeName does indeed have a non ASCII > character (hence the ldhName), as just copying the string from the > document into any viewer shows purely ASCII characters. > Maybe we should use guidance from RFC 7997? > And since it is JSON: > > "ldhName" : "ns1.xn--fo-5ja.example", > "unicodeName" : "ns1.f\u00f3o.example", > > > 5.4 Nitpick > > "href" : "http://example.net/ip/2001:C00::/23";, > > Why uppercase characters are technically allowed per RFC7482 ยง3.1.1 as it > says RFC 4291 formats are allowed and 5952 is only RECOMMENDED (which > specifically calls for lowercase only), it is still RECOMMENDED, so there > should > be valid reasons to ignore it, and in this example it is not clear why it is > not > followed, so maybe simpler to just follow the recommendation? > > > Also, the explanation for "status" should refer to section 4.6 > like other parts do. > > > 9. > If we are not in the just errata types of changes, I really recommend > a more "programmatic" way to signal truncation, instead > of having to rely on a specific string. Like using a boolean. > Deployments in the wild show that this string varies among servers. > I know that it is a registered string in IANA registry (so servers shouldn't > vary > in theory), but I still > feel uneasy for an automated interface to have to rely on human strings > to decide what to do. > (especially when one of the reason given to favor JSON over XML is that > it is less bulky) > > 15.2 Nitpicks > > https://secure-web.cisco.com/1n_IpHslw- > LLCMuu5QUV4Lywyxl7Zw7jsRk_jlusbxbaqWngp5UJ7qt6awNKo2l5LsxsudaH- > y_HhXmqEdM3Wk8jPzDczGsJHH5JtRro34OgWuP5kApjBYrFKvmko4IbzYv0XkJ > uev1U7OxhgV6fgtQOcx22hKHtmD9gyKumALcGjCHJKw_3m6YEheOfUH8A- > N6kj4hcxKFY2K3wkcG9rY4Pu0UBWHD2F8w4_zkBOWEMBort77E5KNoR8zWX > Qx- > o4eak_DarWCMZsSs4elpwGrw/https%3A%2F%2Fdevcentral.f5.com%2Fs%2 > Fweblogs%2Fmacvittie%2Farchive%2F2011%2F04%2F27%2Fthe-stealthy- > ascendancy-of-json.aspx is today a 404, so not really useful. > > For > http://secure-web.cisco.com/141YW_PfA508VT6T6Dqt7nKZJDQ8czL4- > FVZF408HiR1o4DWzE_X3CnPn0bl1Is2dqvB8fHsDFbA- > l60a1AhiZdCohCSsA_EBybtY1NIgNEu9HaMmjUH82G8aYEM5Ty_9-FCEzj5AIU- > qT1J_u11rBOYcRwPRlAwx7qPhw- > lPquUcIG4trMyOLoXdEQm1Ai0IqIbKzCfLF7PgU8RKaoQ746sQu85RANh8x_8Bt > WjLweo4ekahjSTrBcftAzUeG5881Ds5I2B48C2ilzNQWpng4VN8iGoaQ8z6Q8uB > hwlmJuA/http%3A%2F%2Fwww.iana.org%2Fdomains%2Fidn-tables > maybe use https:// instead. > > Same for http://secure-web.cisco.com/1Z- > vlcEAhtgcUzjGDACcnU1o3wnRnWFLS7Np9g1GhHdXyggixazay3- > opBNnCsvm3rPO3CdB08cy25xNV97GX5N0Q1fjryYF90SHT2xSVpnfGSiGKy-s2- > dPw3MHMFZ5d1o7ZNdGE- > cw0zJjL0j59aeP_lyQSz76nTC1PZWMcQ_FsYltVPcvstUtKcp6i_FJP4ltiknXdcSBX > q1cv8BfZkKAssogfHVobluV33ajG33Qd3pVoODzpInnKYMWu3CZw7JPI_31yLX > ZC03bEUvzIbQ/http%3A%2F%2Fwww.cs.montana.edu%2Fizurieta%2Fpubs% > 2Fcaine2009.pdf > > (both do an automatic redirect from http:// to https:// anyway) > > > > > And with all planned changes to RFC7483, it is time to introduce > rdap_level_1 > in rdapConformance values? > If we say: "we shouldn't because clients will not be upgraded, etc.", > then I believe rdapConformance is not useful, if it can not be used as an > upgrade > path. We might as well consider then that rdap_level_0 is a kind of > hardcoded > constant. > > -- > Patrick Mevzek > p...@dotandco.com > > _______________________________________________ > regext mailing list > regext@ietf.org > https://secure- > web.cisco.com/19hy_uSuQ7ymESjnI6rLBR_KRE_2xE7ViCH1no0YDnvx_e0ENd > J9fjWlEp2VgZFXqF4aRT9Yx1J4299qXO5XY-il2dND729Fz-4f- > 0x8WwJxxxH0nY66x9aGdaaCbHCwlUVscNathDwDxvLDAPwaHAO3L0CJ_yBHF > oyNveDPAWqmi0kMf4ZJX5NkRcV_qCxSdP5EA26GguNpN9GJsTVCjChl3cwM > P_WbIUpX2PXvr9AUJykX2sZRTp3GMqpRhrk8bbCJNmPMZwwEp0i9BGAbgeo > 5HdVWOykDhOoOtRlpGCno/https%3A%2F%2Fwww.ietf.org%2Fmailman%2 > Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
