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

["Forrest J. Cavalier III" <forrest@xxxxxxxxxxxxxxx>]

Frank Ellermann wrote:

> Yesterday Charles wrote something in the direction of
> SHOULD NOT => permission, and now you apparently propose
> SHOULD NOT => allowed.  Do all here think that a SHOULD
> (NOT) is something like "please (not)", or worse that
> SHOULD NOT is just a shorthand for "of course you can" ?

"All" here?  Please don't be ridiculous!

We need not care about people who cannot read and
correctly understand RFC2119 language.   We can ignore
that they exist when writing.

That leaves us with the ability to use RFC2119 terms
as defined.  So "SHOULD NOT" means "do it this way
only if you have no good alternative in full awareness
and consideration of the pain you cause yourself or
others."

> There is a reason to allow generation, legacy software.
>
> Decreeing that legacy software is non-conformant without
> good reason is also a dubious idea.  And in my parallel
> universe it's not allowed to implement any new software
> generating GMT if the specification says "SHOULD NOT" -
> legacy software is the only possible excuse in this case.

There are N different ways that legacy software will not
conform to these drafts.  To me, that means that making
legacy software non-conformant is not a serious factor
in making a choice over one wording or another, with timezones or
anything else.

BTW, does RFC2822 use the "MUST NOT" language for this?  Instead
I think it says "zone MUST be within the range -9959 through +9959"
That is subtly different.

A "MUST NOT" is taken to mean that something breaks, so a MUST NOT
GENERATE/MUST ACCEPT may be correct, but I agree is kind of weird.
I like the RFC2822 "MUST generate/MUST accept" instead.  (...which we
need not repeat.)