Hi James, On Wed, Jul 31, 2024 at 03:02:50PM +0000, Gould, James wrote: > Thanks for removing the RECOMMENDED for inclusion of the “geofeed1” > extension identifier. I’m not clear whether requiring the inclusion > of the “geofeed1” extension identifier aligns with the paragraph in > the same section: > > Extension identifier inclusion is not mandatory, because RDAP does > not require that an extension identifier be included in responses > merely to make use of new media types or link relation types. The > main benefit of including the identifier is that it permits a client > to determine that a server does host geofeed URLs, which is useful > where a client receives an IP network object without a geofeed URL, > for example.
Jasdip and I had a further discussion about this, and it turns out that I missed one of his earlier comments about the intent here: On Sat, Jul 20, 2024 at 04:20:20PM +0000, Jasdip Singh wrote: > On Thu, Jul 18, 2024 at 03:19:09PM -0400, Andy Newton wrote: >> 3. What is a client to do if it finds the geofeed link in a response >> without a "geofeed1" extension? Is it suppose to treat the link as if >> the response had a "geofeed1" extension? The expectation of client >> processing should be more explicit in this allowable corner case. > > Glad you noted this edge case. After seeing James’ feedback on > replacing RECOMMENDED with MUST for the extension id inclusion, we > think MUST would be better since it 1) helps eliminate any confusion > on RECOMMENDED being misconstrued as optional, and 2) brings this > extension more in line with the new “marker” extension definition > from the RDAP Extensions draft [2]. If MUST is acceptable, that > still leaves the scenario of a server returning a geofeed link > without this extension id in the response but that would not be in > line with this spec and the client is free to proceed as it would > for any non-standard data in a response; most likely, ignore. > > [2] > https://github.com/anewton1998/draft-regext-rdap-extensions/blob/main/draft-regext-rdap-extensions.md > To clarify this part, the MUST is about setting out how the extension identifier is to be used, *after* the server has decided that it wants to signal to the client that it hosts geofeed URLs for its IP network objects and includes geofeed URL link objects in its responses to clients. The intent is not to require that any RDAP server making use of the "geo" link relation or the "application/geofeed+csv" media type must also include the "geofeed1" extension identifier, or that any RDAP server making use of those values within IP network objects must also include the extension identifier. While all (or almost all) RDAP servers that include geofeed links in their IP network objects per this specification will also be hosting geofeed URLs for those networks, such that signalling that fact to the client would be a sensible thing to do, we don't see how it's open to 'gate' the use of a registered link relation or a media type in this way. Section 4.2 of RFC 9083 (https://www.rfc-editor.org/rfc/rfc9083.html#section-4.2) does not e.g. limit the use of link relations or media types to a certain set, and then say that any other relations/types to be used in RDAP need to be documented as part of some extension and can only be used within the context of that extension. To hopefully further clarify the section, we plan to replace the second paragraph of the "Extension Identifiers" section (i.e. "Extension identifier inclusion is not mandatory...") with the following: An RDAP server may make use of the "application/geofeed+csv" media type and the "geo" link relation defined in this specification in its responses without including the "geofeed1" extension identifier in those responses, because RDAP servers are free to use any registered media type or link relation in a standard response (without implementing any particular extension). The additional value of the extension identifier here is that it signals to the client that the server hosts geofeed URLs for its IP network objects. This is useful where a client receives an IP network object without a geofeed link object, because in that case the client can infer that no geofeed data is available for that object, since the server would have provided it if it were available. Does that help? -Tom _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
