--On Wednesday, June 20, 2018 14:59 +0100 Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote: > Hi SM, >... >> Not taking any action to update the registry defeats the >> purpose of having the registry. > Adding a note about the extension being moved to Historic is > reasonable. Removing the entry is not. While I agree that adding a note is reasonable and that providing a reference to current status (as viewed from the IETF's perspective) is probably more so, I think "defeats the purpose" is wild hyperbole or worse. There are actually two goals of this registry. One is simply to avoid inadvertent name collisions and that certainly is not facilitated by hiding or dropping names unless we somehow want to encourage their reuse. The other is to allow the client maintainers who see a service extension announcement (or server maintainers who, in violation of 5321, see a service extension request) to easily look that purported extension up and see what it is about. Unless the IESG has a magic wand that will cause any and all uses of Sender-ID to disappear the instant that this action is taken, it is _very_ important that the registry entry remain and that it point to useful information, both about what Sender-ID is/was and why the IETF now claims it is Historic and, presumably, is making a "NOT RECOMMENDED" (see 2026) statement about it. At the risk of kicking a dead horse, the above is precisely why I prefer to see RFCs published to cover cases like this (as Applicability Statements for present or former standards track documents) rather than simple tracker notes. I don't actually care about Sender-ID or friends. The original documents were Experimental, an explanation has been published about why the experiment was concluded and these approaches were not viable, and, if the tracker note is sufficiently clear about why the action is being taken _and_ registries updated with appropriate "HISTORIC" and "don't use this" notations and references, I think this approach is probably ok (although not my first preference). However, I recommend we use this discussion as motivation to discourage tracker-style reclassifications to Historic for standards-track documents when the intent is to convey a "don't start using this is you are not and, if you are, please start phasing it out" sort of recommendation. >> I suggest considering Section 2.2 of RFC 5321. > > I am happy to be proven wrong, but I don't think it covers the > case of an SMTP extension being made historic. I think that section is irrelevant to this discussion except to the degree that it explains the reasons for having registry entries (and keeping them there and keeping them up to date). If someone thinks that is not explained adequately, please file an erratum -- I still assume that the time will come in which a replacement to 5321 will be appropriate and, while I'm keeping notes and a working version of a revision, relying entirely on that is probably not wise. best, john
