Hello James, Thanks for your feedback! Please find my comments below.
Jasdip From: regext <regext-boun...@ietf.org> on behalf of Gould, James <jgould=40verisign....@dmarc.ietf.org> Date: Tuesday, March 19, 2024 at 11:58 AM To: regext@ietf.org <regext@ietf.org> Subject: [regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback Ahead of the REGEXT meeting later today, I took the opportunity to review draft-ietf-regext-rdap-geofeed-02. Overall, I found the extension to cover some useful aspects for implementers. Below is my review feedback that can be further discussed at the meeting: It's interesting that the extension doesn't define a new RDAP response member but defines a new "links" "rel" type and a new media type. This defines a new form of extension that could be leveraged in the future. This form of extension can be considered in the content of draft-ietf-regext-rdap-extensions. [JS] It seems the “marker” extension type from the RDAP Extensions draft [1] should cover this extension since marker extensions “exist to denote the usage of values placed into an IANA registry” and we are doing so for the new geofeed link with new IANA registry values for link relation type and media type, and would for redaction as well (per your suggestion below). However, it might be helpful to expand the definition of a marker extension in that draft to include this use case where an extension is simply based on new links, instead of new fields and/or paths. I'm curious whether the "geo" type could be used for other RDAP objects (existing or new). [JS] If you meant the “geo” link relation type, then yes, it could be used to define new geographical web links. But one would need to define a new RDAP extension with a new media type (say, representing location information for an organization). Should the draft be made more generic to apply to any RDAP object, inclusive of the IP Network object class? [JS] That’s an interesting idea but since this extension aligns with RFC 9092bis [2] and the geofeed semantics are closely tied with IP networks, only the IP Network object class is extended here. However, that doesn’t impede such semantics from getting imported into other object classes if an IP Network object is included within. For example, “networks” within an Entity object. But that’s the extent of it. Wouldn't it be better to have the extension identifier set to "geo" to match the new "rel" type used by the extension? [JS] We went back-n-forth on this and settled on “geofeed1” for extension identifier, “geo” for rel type, and “geofeed” subtype for the new media type. Both the extension identifier and media type have the “geofeed” literal in them because they tightly connote the geofeed semantics. However, per our interpretation of the guidance from section 2.1.1 of RFC 8288 [3], the rel type is intentionally set to a more generic “geo” name to connote “a lint context having a resource with some geographic information at the link target”, thereby allowing other geofeed media types, or media types representing some other geographic information, to be registered in the future. (For the record, Massimo Candela (one of the RFC 9092bis authors) suggested using the “geofeed” rel type to avoid any confusion and tightly tie the rel type to the media type. We explained the rationale for using “geo” and there was no further discussion on this.) I'm unsure whether there is the need to redefine the "links" JSON values that is defined in Section 4.2 of RFC 9083 other than the use of the "rel" value of "geo" and the recommendation to use "application/geofeed+csv" for the "type" value. [JS] OK, we can remove the “value” and “hreflang” explanations here and instead start with pointing to section 4.2 of RFC 9083 and then explaining “rel”, “href”, and “type” since they detail the constitution of a geofeed link. I recommend including a registration of the "Geofeed links" redacted "name" in the RDAP JSON Values registry with the "redacted name" type field. If registered, the "description" member can be changed to a "type" member. [JS] Good idea. Will do. [1] https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-00.html [2] https://www.ietf.org/archive/id/draft-ietf-opsawg-9092-update-11.html [3] https://datatracker.ietf.org/doc/html/rfc8288
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
