Hi John,
At 09:08 AM 20-06-2018, John C Klensin wrote:
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.
I did not suggest removing the entry as it might make it difficult
for people to look up information about SMTP extensions.
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
Yes.
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.
Yes.
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.
Several years ago, there was a discussion about this experiment. It
was not viable to do the reclassification at that time. I don't
think that tracker-style reclassification is a good idea. Anyway,
you explained it better than I could.
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.
I am not inclined to file an erratum on this as it would be
ill-thought-out. :-)
Regards,
S. Moonesamy
