expedience, consensus and editing

[Adam Back <[e-mail]>]

Dave Crocker / IMC <[e-mail]> writes:
> Jon Callas writes:
> >The compromise that I, as editor am working with (with thanks to Ian Brown,
> >who came up with it) is as follows:
> 
> Jon, those who serve as working group chairs and document editors have a
> difficult job.  They are usually senior, talented folk.  They get to work
> hard and almost never are adequately appreciated.
> 
> Worst of all, they are often architects who do not see their own
> preferences chosen.
> 
> The editor of an IETF working group document is required to be responsive
> to the rough consensus of the working group.  I hope no one has forgotten
> this minor point.

I would like to see more rapid progress in this forum.

I am subscribed to ietf-smime also, and the rate of progress there is
much quicker.  Suggestions are made for modifications, the active
editor says after some discussion, "ok added this, hows this", etc.
Consensus appears to be followed with minimal political intrigue.

Multiple revisions per day.

So can we have a decision on what is the consensus on these four
items:

1) armor MAY/SHOULD/MUST?
2) MIME as MAY/SHOULD/MUST?
3) 32 bit int clean up shelved for OpenPGPv2, or discussed now
4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2,

My suggestions are:

1) armor MAY

2) MIME SHOULD (with update to rfc2015 where missing parts)

3) shelve until for OpenPGPv2

4) define subpacket type 10 as reserved for future use and get on with
   things.

I already made 2 detailed posts explaing reasons for my recommendation
for 4, and have had 2, or 3 people agree with my conclusion and have
seen no disagreements on list.

It seems the least controversial path, and the quickest path to take,
and doesn't affect compatibility.  The alternative of hashing out a
consensus here of which method best allows for lost passphrase
recovery seems that it will take forever.  PGP Inc seem to be using
message snooping techniques which reduce communications security to
implement passphrase recovery, which in my and most of the non-PGP
peoples opinion is bad design.

Let's not get adventurous, and let's not have a massive brawl over
controversial experimental features, and let's not perform the 32 bit
clean up operation with OpenPGPv1, or it will delay the delivery date
enormously.

Adam