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?
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://devcentral.f5.com/s/weblogs/macvittie/archive/2011/04/27/the-stealthy-ascendancy-of-json.aspx
is today a 404, so not really useful.
For
http://www.iana.org/domains/idn-tables
maybe use https:// instead.
Same for http://www.cs.montana.edu/izurieta/pubs/caine2009.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://www.ietf.org/mailman/listinfo/regext
