Murray said in a previous discussion:
Which means you're also given the option to know what the signer's
notion of the signature's validity time is. And you're free to
ignore it too.
If the signer doesn't provide it, the receiver has lost the choice
to ignore it or use it.
I can't say for sure that anyone is or isn't using it, but I would
prefer not to remove flexibility that's there now even if it was
possibly a mistake for it to be there in the first place (unless of
course it's clearly harmful).
Stepping back for a moment, we have a number of questions that are on
their surface reasonable questions.
For some set of features, should a given feature be removed?
That's reasonable to ask, but I realize from Murray's words that he's
right in the general case as much as for the specific feature.
Standardization is a process of compromise. In the IETF, we pronounce
compromise as "rough consensus." In any compromise or rough consensus,
there are things that are controversies. For my purposes here, I will
define "controversy" to be anything that is not unanimous.
Someone who likes a controversial thing can legitimately claim that
these seemingly-reasonable questions are in fact a subversion of the
process of rough consensus. Right now, I basically agree. We approved
4871 only two years ago. That is *barely* one software development
cycle. Anything that is present in 4871 as a part of rough consensus,
should not fall out of 4871bis unless there's a *strong* consensus
that it go away.
This is especially true for the features that are undeniably
controversial. l= leaps to mind as undeniably controversial. Some
people loathe it, some people love it. (I am, as I've always been, in
the middle where I see both sides of that one.) But the fact that it
is truly controversial is why is should stay. Removing a controversial
feature because it is controversial flies at the very process of rough
consensus, and I think we just shouldn't go there.
I thus now believe that if a feature is in 4871, it should stay in
4871bis unless there is strong consensus to remove it. Surely there
must be one or two of those, but the mere presence of a large
discussion indicates that it needs to say.
Jon
PGP.sig
Description: PGP signature
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html