Hi Tom,

Please check inline below.

On Thu, Jun 5, 2025 at 3:27 AM Tom Harrison <[email protected]> wrote:

> Hi Ketan,
>
> Thanks for your review and feedback.
>
> On Tue, Jun 03, 2025 at 01:19:53AM -0700, Ketan Talaulikar via Datatracker
> wrote:
> > I have a couple of comments/suggestions to share:
> >
> > 1) The use of "geofeed1" tripped me as well. Is it a version (i.e.,
> likely
> > there will be more?) then perhaps "geofeedv1"? If not, I don't really
> have a
> > better suggestion.
>
> We've added text to the document clarifying that this is operating as
> a version number.
>

KT> Thank you. It is clear now.


>
> > 2) In section 2.2, for the following text in v12
> >
> > CURRENT
> > In such a case, the server SHOULD provide "hreflang" members for the
> geofeed
> > link objects. Except for the multiple-languages scenario, the server
> SHOULD NOT
> > return more than one geofeed link object.
> >
> > I have an opposite position to that of Med and preferred the use of the
> MUST
> > NOT (which was in v11). Leaving things open will make it harder for the
> clients
> > on how they would handle multiple objects and what that means - use the
> first?
>
> We note the subsequent conversation here between you and Med on this
> topic.  Our understanding of Med's feedback is that the original "MUST
> NOT" is incorrect, because it's preceded by an exception, which is
> contra the "absolute requirement" text from RFC 2119.  However, as you
> note, the "SHOULD NOT" in conjunction with the "Except ..." text
> implies that there may be scenarios in which multiple geofeed link
> objects (without different "hreflang" members) can be returned, which
> is not something we want to permit.  It's not clear to us at this
> point what we should do with this text.
>

KT> I think I understand the intent of the original text. How about the
following (simplified) rephrasing? Please see if it captures the intent of
the authors/WG. And you can wordsmith it to fit better.

SUGGEST
An IP network object returned by an RDAP server MUST contain either zero or
one geofeed link object except in the scenario when the server is able to
represent that data in multiple languages. Only in those exceptional cases,
the server MAY return more than one geofeed link object and it SHOULD (or
MUST?) provide "hreflang" members for those geofeed link objects.


>
> > I would also ask if there is a reason for the SHOULD in the previous
> sentence
> > and why it can't be a MUST as well. While the handling by the clients is
> out of
> > scope of this document, please do think hard and long on what would make
> things
> > easier and well understood for the clients. In any case, I will leave it
> to the
> > authors and WG since I don't have a good enough understanding of this
> space to
> > give concrete suggestions.
>
> In the common case, a geofeed file will not have a specific language,
> since it contains only IP address information, country codes, region
> names, and city names.  However, we wanted to leave the "hreflang"
> option open, so that servers could translate region/city names if they
> wanted to do that.
>

KT> Got it. I hope I was able to capture this in the suggestion above.

Thanks,
Ketan


>
> -Tom
>
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to