[Top] [All Lists]

Re: Draft to Full, versus cycling at Draft

2010-08-11 13:28:06

--On Wednesday, August 11, 2010 09:41 -0700 Dave CROCKER
<dhc(_at_)dcrocker(_dot_)net> wrote:

My note, here, isn't about that.  It's a 'process' question,
meant mostly for academic consideration:

    Is this the sort of change that is appropriate for going
from Draft to Full?

I would have thought that it was too technical and substantive
and that, at the least, the doc would have to cycle at,
perhaps, Draft.

To repeat:  this is meant purely as an academic exercise.  I'm

Dave, purely personal opinion and in the context of your
proposed academic exercise...

My understanding of the "what can be changed during advancement
in grade" question has always been "no new requirements that
would cause a conforming implementation to become
non-conforming".   That actually raises a separate, even more
academic, question, which is whether violating that rule forces
recycling at Draft or sends one back to Proposed.  If there were
really a new requirement, one might reasonably be required to
publish and then demonstrate that the condition was implemented
and described in an interoperable way.  That would require going
through Proposed under the existing rules.

For the particular 5381 case, my suggested text was quite
consciously intended to avoid running afoul of that question.
The existing text is guidance, my proposed new text is guidance,
and all it really says is that SMTP server implementations are
required to consider the tradeoffs.  That isn't a testable
conformance requirement so the issue of change of grade should
be irrelevant.

Actually changing the timeout requirement would be a
conformance-affecting change but, given that it is stated as a
minimum time to wait, I think only if we increased it.

academically and hair-splittingly yours,