Lutz Donnerhacke wrote:
I do have an application for this type of signature without providing the
full meaning of notary (0x50) signatures.
When you say "I do have ..." are you saying that this
is in existence, or that you are proposing this as a
potential future use of 0x40 sigs?
[description of App elided]
Should I provide detailed description, or should we remove the whole part?
There are three reasons against your suggestion.
One, that you seem to be defining a new app for an
apparently unused but similar feature. If it is only
a similar application, then we'd want to show that
there are no extant uses of the allocated 0x40 code,
etc, so that we don't end up with any confusion.
(It's relatively ok for implementations to be confused,
but the standard should not be...)
(I guess it would be fine to *document* the prior use
of the feature, from code.)
Secondly, even if you could show that the old number
was out of use, I'd still suggest formatting a new
application with new bits and bobs, new meanings,
and new text. Unless we are running out of bits in
some obscure sense, I think it's better to leave old
uses to die, and allocate new codes to new purposes,
even if close.
Thirdly (as I mooted in a prior post) I think we should
be seriously considering putting the RFC process into
feature freeze. So if there is anything *new* about
this, such as a meaning, or an app still to be written,
then I'd say the onus would be on the proposer to
carefully make the case that this should go forward.
E.g., once in feature freeze, we should switch attention
to chopping deprecated and other dead-wood out there, and
to fixing grammer and spelling and whatnot, and thinking
about how it is that the darn thing gets finished.
iang