Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal de

On 2/10/2018 9:59 AM, John R. Levine wrote:
> > MIME was in significant use quite a bit before ESMTP was operational. 
> > In fact it's a non-trivial feature that MIME only requires adoption by 
> > author and recipient and not by /any/ of the infrastructure.  IE, not 
> > by SMTP.
> Yes, I know, but I wish you'd read what I've said about 8BITMIME.  It's 
> an overlay that makes an INCOMPATIBLE CHANGE TO THE MESSAGE FORMAT, 
> which is a version change in any world I know.
The problem is that you are conflating and/or missing some basic points, 
relative to my thesis, which is that a distinct 'version' flag is 
essentially never useful.
First, 8bitmime changes what is permitted for encoding, not basic 
'format' or semantics.  (For this discussion, that's a nit, but still...)
Second -- and really quite fundamental -- 8bitmime is a negotiated 
feature during an interactive session.  The SMTP server gives the SMTP 
client permission to use it.  DKIM is a unilateral mechanism: there's no 
interaction; there is no 'permission' to give.  There is only signaling 
the fact of usage.
Third, 8bitmime is not a version flag, distinct from the protocol 
feature changes being changed, which is the point of this thread.  It is 
the change itself.  The signalling function, that there is a new feature 
-- ie, a different 'version', to employ your apparent usage of the term 
-- is implicit and integrated, rather than distinct and explicit.

> Ditto EAI.
>
> > The SMTP extensions to support MIME characteristics are value-added, 
> > beyond the basic MIME capability.  In other words, they aren't necessary.
> Well, sure, neither is DKIM, you could authenticate your mail some other 
> way.  I don't understand what point you're making here.
That's not my point.  DKIM won't work without... DKIM.  SMTP /will/ work 
without the MIME extensions.
More generally, you have fallen into using the term 'version' for every 
specific enhancement.  While that has linguistic validity, it does not 
have real-world relevance, with respect to a protocol 'version' parameter.
A version parameter is distinct from other syntactic and semantic 
aspects of the changes that are being signaled.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html