Hi Jasdip, Comments in-line
On Mon, Mar 25, 2024 at 7:25 PM Jasdip Singh <jasd...@arin.net> wrote: > > [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 agree with this. > > > > 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.) Also agreed. > > > > 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. Is this really necessary? Under what conditions will a network operator be publishing this public CSV file that then requires an RIR to redact the link to it? -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
