[Top] [All Lists]

RFC2821bis-01 Issue 16: General "is permitted"/ "is not permitted" language

2007-04-07 08:31:00


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.


<Prev in Thread] Current Thread [Next in Thread>