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

["Gould, James" <[e-mail]>]

Tom,

Yes, that helps clarify the intent.  

Thank you,

-- 

JG 



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 




On 8/1/24, 8:53 PM, "Tom Harrison" <[e-mail] <mailto:[e-mail]>> wrote:


Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 


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://secure-web.cisco.com/1uKKLpO3etia2bgNaiQ16MX8Z32n6B-NCMx3TooZlYdvMf3Mvkruxnm4MC1SxOpZEuwDHs0BwPPifvcrJg6VkI_C3NRUYgHEss1DXTjdyozQEDFts84J8HB0JBrK4pZPIF55ejSuJFnzPeeJUsU4u49KkJo1mFSBtxwFoekgjcEt-veoAk0LPHWaqJ_vMdiEOJxVnV7d207nc4fw53x1tlEwrTjGZRCLRy94sGfB3UFA_8WDEQE3YdBd53I5l7hwbztZnkGA7ZPsly1LBTF1ZWrTH8dzkndEFJHzPVcqJNos/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fblob%2Fmain%2Fdraft-regext-rdap-extensions.md <https://secure-web.cisco.com/1uKKLpO3etia2bgNaiQ16MX8Z32n6B-NCMx3TooZlYdvMf3Mvkruxnm4MC1SxOpZEuwDHs0BwPPifvcrJg6VkI_C3NRUYgHEss1DXTjdyozQEDFts84J8HB0JBrK4pZPIF55ejSuJFnzPeeJUsU4u49KkJo1mFSBtxwFoekgjcEt-veoAk0LPHWaqJ_vMdiEOJxVnV7d207nc4fw53x1tlEwrTjGZRCLRy94sGfB3UFA_8WDEQE3YdBd53I5l7hwbztZnkGA7ZPsly1LBTF1ZWrTH8dzkndEFJHzPVcqJNos/https%3A%2F%2Fgithub.com%2Fanewton1998%2Fdraft-regext-rdap-extensions%2Fblob%2Fmain%2Fdraft-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://secure-web.cisco.com/1Yw2Vrm9wlctnSPC-7Gj9spiscpPeQcUkLOkMEHHWD2uqgu831eSJHFMJhgVC4AMC2Tx9nq_lQ19Xu5D36PY6A8Itwv5MXA30OOTw3Nv7oiKq2IlGDLtTFBZfYHiMNqNZl0vm9VoCuKg4lmU81gG4gjOpsOSF0553WHalAr8iuJZulFtH6yK4PWWAg3PMYpAaDoOFQKxDIEs-3T9e3jo6VW3dD1reGjQ7E5f6DnJclUKneilulFO8o8WYIScjSFKUUoXAa4nAs691B0crdKVh-CXD2zTstvVuz5V90HoWwnw/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9083.html%23section-4.2 <https://secure-web.cisco.com/1Yw2Vrm9wlctnSPC-7Gj9spiscpPeQcUkLOkMEHHWD2uqgu831eSJHFMJhgVC4AMC2Tx9nq_lQ19Xu5D36PY6A8Itwv5MXA30OOTw3Nv7oiKq2IlGDLtTFBZfYHiMNqNZl0vm9VoCuKg4lmU81gG4gjOpsOSF0553WHalAr8iuJZulFtH6yK4PWWAg3PMYpAaDoOFQKxDIEs-3T9e3jo6VW3dD1reGjQ7E5f6DnJclUKneilulFO8o8WYIScjSFKUUoXAa4nAs691B0crdKVh-CXD2zTstvVuz5V90HoWwnw/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9083.html%23section-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 -- [e-mail] <mailto:[e-mail]>
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>