Response in-line. On Sat, Dec 10, 2022 at 4:41 AM Mario Loffredo <[email protected]> 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? > > > 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? > > > 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. -andy _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
