Hi Andy,
again my comments below
Il 13/12/2022 19:38, Andrew Newton ha scritto:
On Tue, Dec 13, 2022 at 12:12 PM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
The entity lookup URL MUST always be used regardless of the query generating
the response including the contact card.
Does it work for you?
JSContact says that it SHOULD be a URN in the uuid space and MAY be a
URI. Why deviate from that? Can it not be a URN in the UUID namespace?
[ML] Didn't want to ask the implementers for an additional effort.
Excluding the case that the UUID is created once and stored, to keep the
same UUID across different responses including the same contact, the only
alternative is to generate it from the handle value through an hash
function. As a Java programmer, I know it is possible and provided by
some libraries. Honestly, can't say the same for other languages.
Since an URI is allowed, it seemed to me better to propose an univerally
unique URI that could be easily generated.
UUIDs are pretty standard things, and I wouldn't be surprized if
implementers let their database do the work anyway as many DBs have
functions to generate them. But implementation considerations are a
good thing.
Perhaps follow the guidance in the JSContact draft... SHOULD be a UUID
URN, MAY be a URI where the URI is the entity URL.
The use of JSContact is supposed to bring other benefits because it is
a standard used in other places. The further we stray the further
those benefits erode. Otherwise we should just use our contact model
such as that found in EPP and the original RDAP drafts.
[ML] Your suggestion about how to rephrase the sentence sounds good to
me. I'll change the text accordingly and the examples by using URNs in
the UUID namespace.
Nevertheless, should I add text stating that, being uid mandatory, it MUST be
redacted by the emptyValue redaction method as defined in
draft-ietf-regext-rdap-redacted ?
That seems to work, but should this go in the redacted draft instead of here?
[ML] Think this document is the right place. The redacted draft defines
the redaction methods and this document defines an extension that makes
use of one those methods.
The issue is that you are now entangling the two docs in the
publication process.
[ML] Maybe I didn't catch the exact meaning of this sentence but I think
just the opposite. In addition to the conceptual reasons, making the
rdap-redacted to reference rdap-jscontact would result in a circular
dependency between the two documents.
@James Gould: Could you please give your opinion on this point?
Mario
-andy
--
Dott. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
