3.Chapter with "minimal changes deemed useful to improve
the viability
of services that are based on these specifications" is
not acceptable
to me.
I, OTOH, find it totally unacceptable to remove this language
entirely. Without this language the chances are excellent the
group will rathole and never produce anything. Of course I'm
biased about the current language since I'm the one who came
up with part of it, but I think it strikes the right balance
between allowing necessary changes and disallowing
superfluous introduction of unnecessary alternatives.
I would prefer it if the language emphasized backwards compatibility
rather than making minimal changes.
From a purely pedantic point of view we can imagine a situation in which
we ended up with a document that changed 50%+ of the document text
without changing the semantics of the protocol at all.
I can also imagine making changes to the specification of the
canonicalization algorithms that are far from minimal but do not impact
the installed base of signers (e.g. disallow certain MIME tricks that it
is most unlikely any existing signer would introduce.
Removing this sentence all together or removing word
"minimal" and
replacing it with "all necessary" would help.
I guess I could live "all necessary", but I much prefer "minimal".
I dislike minimal because it implies that there is a strong bias against
change of any kind rather than a particular bias against change that is
going to disrupt the installed base. One of the reasons I argued against
having three C14N algorithms in the original specs was that I thought
that we should leave open the opportunity to create an additional one in
the MASS group if it turned out to be needed.
Possibly also add "The group will look into interaction
of proposed
authorization methods with deployed PKI X.509 and OpenPGP
infrastructures".
I am sympathetic to wanting to define additional mechanisms,
if only to insure that implementatiosn actually allow for
them in the future. However, the proposed text here goes
much, much, much too far.
How about changing 'will' to 'may'?
It would seem somewhat sub-optimal to me to have to submit my DKIM/PKIX
draft as a personal submission and have the WG unable to discuss it or
propose any changes.
On the other hand it seems unnecessary to promise this as a deliverable.