That works; thanks. Cheers,
> On 17 Apr 2025, at 5:59 am, Jasdip Singh <[email protected]> wrote: > > Hi Mark, > > Thank you for your review of this draft. Please find below our comments. > > Also, please see [1] for the diffs in the updated draft. > > Thanks, > Jasdip & Tom > > [1] > https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-geofeed-10 > From: Mark Nottingham <[email protected]> > Date: Saturday, March 15, 2025 at 3:31 AM > To: [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>, Julian F. Reschke > <[email protected]>, Julian F. Reschke <[email protected]>, > [email protected] <[email protected]> > Subject: [regext] Re: [IANA #1414866] expert review for > draft-ietf-regext-rdap-geofeed (link-relations) > The description given: > > > Indicates that the link context has a resource with geographic information > > at the link target > > doesn't seem correct; I *believe* the intent is something like: > > > Refers to a resource with geographic information related to the link context > [JS] Thanks for this correction. Updated the description, while also > considering your next comment. > > > Also, the name requested is extremely generic. If the intent is that this use > will be specific to RDAP, the relation name should be correspondingly > specific -- e.g., "rdap-geofeed". On the other hand, if the intent is to > register a generic name, the language in the specification should explicitly > indicate its generic semantics and separate the RDAP case more clearly (e.g., > using a "type" attribute to indicate a media type). Moving the registration > to a separate document would assist in this. > [JS] Agreed. However, to have the specificity balance with the proposed > “application/geofeed+csv” media type, we as authors would prefer to have > “geofeed” as the relation type, instead of “rdap-geofeed”. The rationale is > that this media type would be used by non-RDAP geofeed CSV-processing > applications as well, beside the RDAP-centric applications. Since the > “geofeed” term is commonly used in lieu of the more technically proper “IP > geolocation feed” term from the core geofeed RFC 9632 that this draft refers > to for the RDAP geofeed link purposes, hopefully it is specific enough to be > registered from within the RDAP Geofeed draft rather than needing a separate > document for the relation type. > Updated registration: > * Relation Name: geofeed > * Description: Refers to a resource with IP geofeed location information > related to the link context. > * Reference: This document. > > > > > > On 15 Mar 2025, at 8:24 am, David Dong via RT > > <[email protected]> wrote: > > > > Dear Mark Nottingham, Julian Reschke, Jan Algermissen (cc: regext WG), > > > > As the designated experts for the Link Relation Types registry, can you > > review the proposed registration in draft-ietf-regext-rdap-geofeed-09 for > > us? Please see > > > > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-geofeed/ > > > > The due date is March 28th. > > > > If this is OK, when the IESG approves the document for publication, we'll > > make the registration at: > > > > https://www.iana.org/assignments/link-relations/ > > > > Unless you ask us to wait for the other reviewers, we’ll act on the first > > response we receive. > > > > With thanks, > > > > David Dong > > IANA Services Sr. Specialist > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Mark Nottingham https://www.mnot.net/ _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
