I hereby repent of my sins, which I committed in a previous life. Option A.
G. > On 13 Aug 2025, at 13:55, James Galvin <[email protected]> wrote: > > During our IETF123 meeting the status of “RDAP Extensions” > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/__;!!PtGJab4!6mC1t3YkqZ3ZeM60TMwcw7BjGLn9nyy4iNnQ2YxW5EkJqG9KrfQ6mVyZ396lnuynOUlAiMIOReG0VzZLbfKIcjk$ > [datatracker[.]ietf[.]org]> was discussed. Currently there is one technical > issue that has been under discussion on the mailing list for some time. It > was agreed during the meeting that the Chairs would seek to bring the > discussion to a close by asking the open question on the mailing list. > > The Chairs need your response. We would most like to hear from folks who > have not had much to say up to this point. > > The question is what should the status of bare identifiers be in the “RDAP > Extensions” draft? > > Three possible answers have emerged. The Chairs are opening a poll by > presenting the three choices and asking folks to indicate the option they > would most prefer to support. > > Please note - this is not a discussion. If you have a clarifying question > you may ask and the Chairs will respond. The Chairs are asking you to > indicate which option you would most prefer to support. > > The three options are as follows. > > A. Always disallow them - Bare identifiers can cause confusion because they > do not define a structured namespace. The bare identifiers that already > exist in the RDAP Extensions Registry would be permitted to remain as > specified; new bare identifiers would not be allowed. > > B. Always allow them - They already exist in the RDAP Extensions Registry and > thus we know that they can work. The IANA processes ensure there are no > duplicate identifiers. > > C. Only allow them if it is REQUIRED to solve the problem being considered - > This option is a compromise that would require that guidance exist in order > to evaluate whether or not the bare identifier is the only solution. > > Some additional background information you may find helpful as you consider > which option you would most prefer to support can be found in the following > IAB guidance: > > [1] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc5218*autoid-15__;Iw!!PtGJab4!6mC1t3YkqZ3ZeM60TMwcw7BjGLn9nyy4iNnQ2YxW5EkJqG9KrfQ6mVyZ396lnuynOUlAiMIOReG0VzZLVd5riMg$ > [datatracker[.]ietf[.]org] > [2] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc1958*page-4__;Iw!!PtGJab4!6mC1t3YkqZ3ZeM60TMwcw7BjGLn9nyy4iNnQ2YxW5EkJqG9KrfQ6mVyZ396lnuynOUlAiMIOReG0VzZLyp11TmI$ > [datatracker[.]ietf[.]org] > [3] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/rfc9413*name-protocol-decay__;Iw!!PtGJab4!6mC1t3YkqZ3ZeM60TMwcw7BjGLn9nyy4iNnQ2YxW5EkJqG9KrfQ6mVyZ396lnuynOUlAiMIOReG0VzZLVShrGQc$ > [datatracker[.]ietf[.]org] > > Also note that given there are already some bare identifiers defined in the > IANA RDAP Extension Registry, all existing extensions will remain as > currently specified. The response selected here only applies to new > extensions. > > This poll will close on Wednesday, 1200 UTC, 27 August 2025. Please select > an option and indicate your choice on the list by replying to this message. > > Recall from the meeting that the Chairs proposed that option 1 was the best > course of action. > > Thank you for your prompt attention, > > Jorge, Antoin, and Jim > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
