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

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

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Patrick Mevzek
> Sent: Monday, April 27, 2020 3:51 AM
> To: [e-mail]
> 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