Hi Andy,
thanks for your feedback.
Please find my comments inline.
Il 13/12/2022 15:27, Andrew Newton ha scritto:
Response in-line.
On Sat, Dec 10, 2022 at 4:41 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
Hi folks,
this new version is complaint with last JSContact spec. I also added a section
about registering the JSContact map keys that must be used in the RDAP context.
Since JSContact will hopefully move to IESG next week, I would like to finalize
this document for WGLC.
in addition to your remarks, there are some open points from my side:
1) The "uid" property is mandatory in JSContact. Currently, the document
recommends to set it to the handle value.
As such, currently the value doesn't represent a universal identifier.
To save it from collisions, a possible solution could be to set it to the URL
of the lookup query for the entity related to the contact card as in the
following:
"handle": "XXXX",
"jscard": {
"@type" : "Card",
"@version" : "1.0",
"uid" : "https://example.com/rdap/entity/XXXX";,
....
}
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.
Would like to know other opinions on this point.
2) This is connected to the point above.
Usually, the handle is not redacted.
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.
3) SInce the contact information as described in RFC5733 doesn't include a separate
property for the postal address street details, should I add text clarifying that in the
RDAP context the JSContact StreetComponent type "name" is used to
represent all the street details ?
Optionally, it would be possible to register and then use a new StreetComponent
type value.
This is cleaner and probably a better choice.
[ML] Hopefully before it gets published, JSContact will include a
StreetComponent type value addressing this case (e.g. "fullStreet") so
that no extension will be needed :-)
Best,
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
