From: Pete Resnick (presnick@qualcomm.com)
Date: Mon Jun 23 2003 - 14:31:12 CDT
On 6/20/03 at 12:27 PM -0700, John Stanley wrote:
>Pete Resnick (presnick@qualcomm.com):
>
>>It is therefore necessary to document what everyone expects ...
>
>Which is documented in RFC 2822 where the header is defined.
I think it is clear that the consensus is that a reference to 2822
alone will not suffice.
>I would question the ability of any group to document what
>"everyone" expects...
Sorry, all I meant was "document what the least common denominator of
implementations who do stripping of the beginning of subjects
expects". "Everyone" was just short-hand; don't read in anything
elaborate.
>It's clear that some agents expect "Sv: " since that is what they insert.
Actually, that's not clear. Do we know of implementations that strip
"Sv: " in addition to inserting it? (In any event, we're not talking
about a significant number of implementations doing "Sv: " anymore.)
>>4. Clear: The Informational usage document is not going to be able
>>to use the 2119 keywords exactly as 2119 meant them.
>
>I want to be clear here that you are referring to USAGE and not
>USEFOR by this "Informational" document.
Absolutely.
>There has been mention that since USEFOR is "Informational"
The syntax and semantics document will not be "Informational" as far
as I understand it; it will be standards track.
>it cannot use RFC2119 language. That is incorrect.
Any Informational document which defines a protocol can use 2119. You
are correct.
>>5. Clear: We will be able to use stronger imperative language in
>>the usage document than in the protocol document. The protocol
>>document is identifying things that will break (network
>>interoperability wise) if they are not followed. The usage document
>>is identifying things that will make users lives a pain if they are
>>not followed.
>
>That is exactly backwards.
You missed my point. In the protocol document, we are limited to
using MUST NOT to things that actually cause "network damage" (e.g.,
delivery failures of articles and the like). We can't say MUST NOT to
things that cause "lots of user to be really angry". Even if we had
decided that adding "Sv: " would cause lots of users to be angry,
it's probably not appropriate to use even a SHOULD NOT in that
document.
However, in the usage document, we're only going to be talking about
things that, e.g., "cause users to be really angry". In that
document, we can come up with some system of strong imperatives for
this kind of thing, either defining MUST NOT and SHOULD NOT
differently up front, or coming up with new special terms like,
"WOULD BE BAD", "FORBIDDEN" or otherwise. Because the usage document
does not specify protocol, we can use stronger language to express
how important we think it is.
All that I meant above was that we would have to come up with softer
language for the protocol document if we put it in there. We could
use stronger language in the usage document.
>If you use the RFC2119 method of indicating imperatives, then you
>bring in the RFC2119 meaning.
Not necessarily. Of course, if you say in the document, "We're using
RFC 2119", you get the 2119 meaning. But, if you define those terms
specially for your document (as RFC 2821 did), you can use the same
terminology and capitalization for different purposes. (This is
useful because people will recognize "MUST" as meaning something
special in a document, even if it doesn't -- and pretty obviously
can't in a usage document -- mean what it would in a protocol
document that used the 2119 definitions.)
>And, for the record, _I_ care when people lie about what I've said,
>even if that puts me in the "no one of any importance" category, and
>I thank the Chair for making His opinion on this crystal clear.
Just to make my opinion even more crystal clear: FOR PURPOSES OF
DETERMINING WHAT THIS WORKING GROUP SHOULD SAY IN ITS DOCUMENTS, and
especially with regard to people making claims about whether someone
"wants to get rid of 'Re: '" or "wants 'Re: ' for implementations
that can't handle References", the fact that *you* care about what
people say *is* of no importance and has no impact on the consensus
process in this working group. Now, that doesn't mean I think such
behavior should continue or I personally think *you* are some sort of
"unimportant person" because you care about such lies. But there is a
different mechanism to deal with that: You don't defend yourself on
the list. You report to the chair the unprofessional behavior (and it
*is* unprofessional) of the working group member in question. The
chair will approach that other working group member, likely ask for a
public retraction, and ask for that person to stop. If it becomes a
problem, the chair can ban postings from the offender. Trying to
defend yourself just compounds the problem of the initial lie since
it makes the list that much more adversarial.
(And because we're being crystal clear: No, I don't mean you can't
correct what you think is an innocent misunderstanding of your
position by another working group member; you can of course do that
on the list. And no, we're not going to be revisiting past offenses.)
pr
-- Pete Resnick <mailto:presnick@qualcomm.com> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102