Hi Ketan, all, I’m afraid your new suggested text is not an absolute requirement: “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”. I do still think the text in the draft is correct.
Cheers, Med De : Ketan Talaulikar <ketant.i...@gmail.com> Envoyé : jeudi 5 juin 2025 08:15 À : Ketan Talaulikar <ketant.i...@gmail.com>; The IESG <i...@ietf.org>; draft-ietf-regext-rdap-geof...@ietf.org; regext-cha...@ietf.org; regext@ietf.org; gavin.br...@icann.org Objet : Re: Ketan Talaulikar's No Objection on draft-ietf-regext-rdap-geofeed-12: (with COMMENT) Hi Tom, Please check inline below. On Thu, Jun 5, 2025 at 3:27 AM Tom Harrison <t...@apnic.net<mailto:t...@apnic.net>> 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 ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
