What is or is not an absolute requirement of the spec is for the spec writers (i.e., authors/WG to decide). I am not in a position to pass judgement as I don't have the domain expertise - so I defer to the authors/WG.
Authors: please also check https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ Thanks, Ketan On Thu, Jun 5, 2025 at 7:42 PM <[email protected]> wrote: > 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 <[email protected]> > *Envoyé :* jeudi 5 juin 2025 08:15 > *À :* Ketan Talaulikar <[email protected]>; The IESG <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected] > *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 <[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 > > ____________________________________________________________________________________________________________ > 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 -- [email protected] To unsubscribe send an email to [email protected]
