Thomas, I agree with everything you say below except that some of what
you say may, in fact, be the justifications we are looking for. I
didn't say examples, I said explanations. See below ...
On 11/22/2006 09:06 AM, Thomas Narten allegedly wrote:
Scott W Brim [EMAIL PROTECTED] writes:
I
Hi Spencer,
It's not that specifications need to explain all possible
reasons for not
following a SHOULD - I agree with your statement that
successful protocols
are used in amazing ways - but I do think listing ONE
possible reason as
justification for a SHOULD instead of a
Scott W Brim [EMAIL PROTECTED] writes:
I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity. Many of them have to do with the use
Sharon Chisholm wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Bob Hinden wrote:
Gentlemen,
This document is being recycled at Draft standard. It has been
previously reviewed, IESG approved, RFC-Editor edited, and published
at Proposed and Draft Standard. It is very widely deployed. Any
issues regarding the meaning of SHOULD, MUST, etc. have been
Sharon Chisholm wrote:
Hi
Hi Sharon,
4. In section 2.4.2.1, first paragraph it says Implementations are
encouraged to use short-circuit evaluation in these cases. This seems
an arbitrary and somewhat obvious bit of implementation advice.
This text is trying to say that
