Hi.
In going through 2821bis looking for some other things, and in
conjunction with Issue 4, I've discovered that language about
what implementations are permitted (or not permitted) to do is
fairly widespread in 2821. The two cases identified in Issue 4
(about reply codes) are a tiny minority of the total. Based on
a quick scan, most of these are intended to be informal,
describing operational alternatives, but some are actually
protocol constraints. I think we can:
(1) Do nothing, on the theory that trying to patch these
as a group would be likely to make things worse. That
would probably extend to Issue 4 as well.
(2) Go through these one at a time, generating issues on
a case by case basis. I would recommend against this if
we really want to get the document out.
(3) Extend Section 2.3 to make it clear that, when used
in a protocol context, these terms are fully as
normative as the traditional MAY/SHOULD/MUST.
(4) Have me go through the document, identify the
protocol-specific ones, and change them to
MAY/SHOULD/MUST as appropriate. This would leave
readers needing to check those choices using a diff or
equivalent and objecting if needed.
My personal preference is for (4) or (1), with the preference
shifting to (1) unless at least a few people are willing to
carefully review the choices made under (4) and we are willing
to accept that we might miss one or two cases.
john