> -----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. > > > 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?
Agreed. I'm thinking of doing this to the text: OLD: The string literal "rdap_level_0" signifies conformance with this specification. When custom JSON values are inserted into responses, conformance to those custom specifications MUST use a string prefixed with the appropriate identifier from the IANA RDAP Extensions registry specified in [RFC7480]. For example, if the fictional Registry of the Moon wants to signify that their JSON responses are conformant with their registered extensions, the string used might be "lunarNIC_level_0". These prefixes aid the identification of specifications for software implementers, and failure to use them could result in slower adoption of extensions. NEW: The string literal "rdap_level_0" signifies conformance with this specification. When custom JSON values are inserted into responses, conformance to those custom specifications MUST be indicated by including a unique string literal value registered in the IANA RDAP Extensions registry specified in [RFC7480]. For example, if the fictional Registry of the Moon wants to signify that their JSON responses are conformant with their registered extensions, the string used might be "lunarNIC_level_0". These registered values aid the identification of specifications for software implementers, and failure to use them could result in slower adoption of extensions. > 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. Do you have text to suggest? > 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. We can't change the structure as part of this effort, but if there's an issue here we can create a ticket for it. I'm open to suggested text for a better description of the "type" value. > 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", This is a bug in 7483 and/or the RFC publication process. Those examples are supposed to contain non-ASCII characters. The challenge here is that the characters in question are part of U-labels, so we have to use something that's appropriate for representing a U-label. I think that means that I need to make sure the Unicode characters are preserved when xml2rfc produces the text for the I-D. > 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? Agreed. > Also, the explanation for "status" should refer to section 4.6 > like other parts do. Agreed. > 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) Let’s defer this. > 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. I found a current reference that I'll use for a replacement: https://devcentral.f5.com/s/articles/the-stealthy-ascendancy-of-json > 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) Agreed. > 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. I'm of the mind that rdap_level_1 will be required if/when we actually describe protocol *changes* that require a new Proposed Standard specification. I don't think we're there yet. Thanks for the feedback, Patrick! Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
