Re: #1028 USEFOR 3.1.2 Date: Resolved, I think.

[Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>]

Seth Breidbart wrote:
 
> "MUST NOT" = don't do it.  Period.
> "SHOULD NOT" = don't do it unless you have a good reason.

ACK, and don't use these 2119 keywords where it's unnecessary.
Necessity includes "potential to cause harm".  Or here also
all "differences from 2822".

Based on that I got "don't quote MUST NOT generate GMT", but
it's of course also a matter of taste to a certain degree.

> the question is which is worse: being _more permissive_
> than RFC 2822 (which we aren't anywhere else, are we?) or
> decreeing that legacy software is non-conformant with a
> new spec?

Charles apparently intends to be more permissive about some
length limits (78 and 998), I'm not sure at the moment. 

BTW, it's not that I wanted any explicit "SHOULD NOT generate
GMT", I only didn't like the explicit "MUST NOT generate GMT",
because there's neither a potential harm nor any difference
from 2822.  Maybe that's a bit too shrewd... ;-)

>> in my parallel universe it's not allowed to implement any
>> new software generating GMT if the specification says
>> "SHOULD NOT" -
 
> Unfortunately, some implementors won't agree with you.
> They'll find other reasons that are good enough for them.
> (At least, that's my guess.)

Yes, that's possible.  And Bruce's IMAP "sort-by-date" example
was interesting.  I know nothing about IMAP and trust that Ned
or Bruce would tell us if we're about to screw up.  So far I
don't see a problem, except from "Russ wants some problematic
time zone names as a MUST accept", which would put us back to
square one.  

I'm happy with only GMT, eliminating the complete zone name zoo
is also very tempting.
                         Bye, Frank