ietf-mailsig
[Top] [All Lists]

RE: in regards to chapter

2005-08-02 14:59:19


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.

<Prev in Thread] Current Thread [Next in Thread>