I'm not sure the suggested process would work for problematic cases, e.g. those where there's an intermediate state for registrations pending. It seems like in all of these cases the relationship of events and roles of IANA, document shepherd, IESG, RFC editor, author, AD, WG chair isn't simple, and needs some flexibility and judgement 1 https://tools.ietf.org/html/draft-nottingham-thanks-larry-00 The 418 error code in a registry (from April 1 RFC2324) (but no coffee: in scheme registry) Some RFCs not dated April 1 can have the same issues. 2 The change in ownership of application/pdf (RFC 8118) was it necessary? How else can the owner organization change? 3 The change in registration of text/html from RFC 2854 without obsoleting RFC In this case, how to populate other bits of metadata were of some concern 4 The 'duri' and 'tdb' URI schemes (https://tools.ietf.org/html/draft-masinter-dated-uri-10) can a registration from an I-D be accepted if there's no intention to produce an RFC ever? 5 https://mailarchive.ietf.org/arch/msg/uri-review/Imkhlr8KwsdRmiWeWopEGPa_UDc / Can a registration be based on an archived email containing the specification? -- https://LarryMasinter.net https://Going-Remote.info
<<attachment: winmail.dat>>
