RE: ffpim revised draft

Folks,

I am reviewing comments on the current draft of FFPIM and want to ask the 
working group to resolve any of the normative issues:


At 11:08 AM 3/19/2002 -0800, Dan Wing wrote:
>Is there really an expectation that TIMELY will be implemented when
>DSN hasn't been implemented in all these years?  I mean to say, why
>does 3.0 require support of TIMELY, but doesn't require support
>of NOTARY (DSN)?

Dan is asking a very important, basic question:  Should FFPIM rely on any 
features being implemented as ESMTP options?  That is, should we permit any 
FFPIM features that use ESMTP options be a MUST requirement or would it be 
better (safer) to make them SHOULD or MAY?

Features that use ESMTP options are relying on a change to the SMTP 
infrastructure.  All SMTP systems between the originator and the recipient 
must be changes, for the ESMTP option to work properly.  Therefore, an 
ESMTP option must reach universal deployment, to be of use for the general 
Internet.  As Dan observes, there is significant risk in specifying this 
dependency.

(There is, perhaps, a counter-argument which says that the way to get 
things implemented is to increase the pressure for them, by making them a 
MUST.  I believe that such "de jure" pressure is usually not successful for 
IETF standards, but that is only my own opinion.)


>Section 5 says that FFPIM is an extension of both RFC2305 and
>RFC2532.  Does this mean that an FFPIM implementation must
>conform to RFC2305 and RFC2532?  If so, FFPIM doesn't state
>that anywhere but in section 5, which is the security section.

OK.  I am adding language that says explicitly that FFPIM implementations 
must conform to RFC2305 and RFC2532.

Is this acceptable to the working group?

d/

----------
Dave Crocker  <mailto:[email protected]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.850.1850