Hi Orie,
Thanks. We have incorporated your feedback [1].
We’d next update the media type registration based on the following feedback
from Alexey Melnikov on the media-types mailing list:
“As text/csv has "charset" as an optional parameter and has the following text
associated with it:
In accordance with RFC
6657<https://datatracker.ietf.org/doc/html/rfc6657>
[RFC6657<https://datatracker.ietf.org/doc/html/rfc6657>], the charset
parameter SHOULD be used, and if it is not present, UTF-8 SHOULD
be assumed as the default (this implies that US- ASCII CSV will
work, even when not specifying the "charset" parameter).
it would be good to state explicitly in the media type registration template
that it is not used, because content is always in UTF-8.”
And, then submit the next version of this draft.
Jasdip
[1]
https://github.com/jasdips/rdap-geofeed/blob/main/draft-ietf-regext-rdap-geofeed.md
From: Orie <o...@or13.io>
Date: Saturday, February 1, 2025 at 4:18 PM
To: Jasdip Singh <jasd...@arin.net>
Cc: regext@ietf.org <regext@ietf.org>
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
Hi Jasdip,
That text works for me.
Regards,
OS
On Sat, Feb 1, 2025 at 11:06 AM Jasdip Singh
<jasd...@arin.net<mailto:jasd...@arin.net>> wrote:
From: Orie <o...@or13.io<mailto:o...@or13.io>>
Date: Friday, January 31, 2025 at 9:42 AM
To: Jasdip Singh <jasd...@arin.net<mailto:jasd...@arin.net>>
Cc: regext@ietf.org<mailto:regext@ietf.org>
<regext@ietf.org<mailto:regext@ietf.org>>
Subject: [regext] Re: AD Evaluation: draft-ietf-regext-rdap-geofeed-08
<snip>
## Nits
### Reads awkwardly
```
249 inetnum objects (per [RFC9632]), clients who find a geofeed link
250 object within an IP network object MUST ignore geofeed data from that
251 link that is outside the IP network object's address range.
```
that link that -> any link that ?
[JS] Since “that link” points to “a geofeed link object within an IP network
object”, using “any link” instead would not be correct. We would like to
propose the following text to remove any ambiguity:
“… clients who find a geofeed link object within an IP network object MUST,
after retrieving the geofeed data from that link, ignore any entry where the
entry's IP address range is outside the IP network object's address range.”
Will that work?
yes, perhaps this might read slightly better:
“… clients who find a geofeed link object within an IP network object MUST
resolve the associated geofeed data and ignore any entry where the entry's IP
address range is outside the IP network object's address range.”
The MUST is having an awkward interaction with "retrieving" here, not sure if
it is your intention to make retrieving (dereferencing) a normative requirement.
dereferencing comes with other possible requirements, see:
https://datatracker.ietf.org/doc/html/rfc9110#section-4.3.4 /
https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.2
No, retrieving is not a normative requirement. Will the following work?
“... clients who find a geofeed link object within an IP network object and
opt to retrieve the data from the associated link MUST ignore any entry where
the entry's IP address range is outside the IP network object's address range.”
Jasdip
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
