[regext] Re: I-D Action: draft-ietf-regext-rdap-geofeed-06.txt

[Tom Harrison <[e-mail]>]

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