Hi Med, The "open" part is that the client has to expect that it can receive multiple geofeed link objects (even if their data is not in multiple languages) and come up with some of its own (implementation specific) logic to deal with them.
My personal view is that tighter the spec with less "loose" or 'open" behaviors, the better it is for implementations and deployments. Of course, if there is a good reason for flexibility, then I am all for it. This second aspect is something that I cannot evaluate due to unfamiliarity with this space and hence left it to the authors/WG. Thanks, Ketan On Tue, Jun 3, 2025 at 4:36 PM <[email protected]> wrote: > Hi Ketan, > > On this specific point: > > > 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 > > We have clearly an exception here and the change in -12 is correct. What > do you think is "open" in this specific case? Thanks. > > Cheers, > Med > > > -----Message d'origine----- > > De : Ketan Talaulikar via Datatracker <[email protected]> > > Envoyé : mardi 3 juin 2025 10:20 > > À : The IESG <[email protected]> > > Cc : [email protected]; regext- > > [email protected]; [email protected]; [email protected] > > Objet : Ketan Talaulikar's No Objection on draft-ietf-regext-rdap- > > geofeed-12: (with COMMENT) > > > > > > Ketan Talaulikar has entered the following ballot position for > > draft-ietf-regext-rdap-geofeed-12: No Objection > > > > When responding, please keep the subject line intact and reply to > > all email addresses included in the To and CC lines. (Feel free to > > cut this introductory paragraph, however.) > > > > > > ------------------------------------------------------------------- > > COMMENT: > > ------------------------------------------------------------------- > > > > Thanks to the authors and the WG for the work on this useful > > document. > > > > 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. > > > > 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? > > 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. > > > > > > > ____________________________________________________________________________________________________________ > 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]
