Subject: Re: 2nd suggested revision for MUST/SHOULD

From: Charles Lindsey <[email-masked]>
Date: Fri, 28 Jul 2000 09:39:22 +0100 (BST)

On Thu, 27 Jul 2000 23:30:45 -0400
	Keith Moore <[email-masked]> said...

> 
> several points:
> 
> I see no inherent problem with copying the 2119 definitions for 
> MUST/SHOULD.  However I assume that much of the existing text is 
> based on the 1123 definitions of these terms, so changing might
> require examining every occurance of these terms.  Fortunately,
> the 1123, 2119, and proposed definitions of these terms are quite
> similar.  And I do see value in consistency with 2119, though
> RFCs which deviate from the 2119 definitions are not uncommon.
> 
> However I wonder if the definitions of "fully conforming" 
> vs. "partially conforming" may still be useful, regardless of which
> definitions of MUST/SHOULD are used.  OTOH, I do have some 
> reservations about defining "fully/partially conforming" in this way 
> because (if memory serves) SHOULD [NOT] are sometimes used to avoid 
> having to specify the behavior of each particular kind of MTA 
> configuration.  An SMTP implementation that, for whatever valid 
> reason, doesn't perform every single one of the functions of an MTA 
> (submission, delivery, relaying, aliasing, list expansion, etc) 
> should perhaps be "fully conforming" as long as it meets the 
> SHOULD [NOT] requirements for the functions that it does perform.
> 
> I also think that it's worthwhile to explain 
> 
> - why SHOULD or even MUST might specify something that degrades
> interoperability with noncomforming implementations of this or
> a previous specification.  (interoperability with conforming
> implementations is paramount)
> 
> - that the spec is deliberately tightened as compared to previous
> versions; pre-existing implementations are expected to require
> some changes
> 
> no matter which definitions of MUST/SHOULD/MAY are used.
> 
> personally, I don't think that consistency with 2119 is so important 
> that it necessiates changing the document at this late date.
> but if it helps us get consensus on the document, it might be worth it.
> 
> so at the risk of bogging things down more, here is a 2nd concrete 
> proposal.  the paragraphs not in 2119 are labelled [A], [B], and [C]
> for easy reference in DRUMS discussion, not for inclusion in the
> RFC.

Yes, I think that is better, because the relationship to 2119 is now clear.

But I see little point in repeating the 2119 text in full. Other standards just 
refer to it.

A couple of nit picks:

> [B] ...
> type of implementation) to not follow the requirement.
                          ^^^^^^^^^^^^^
                          not to follow
                       (split infinitive :-( )
> 
> [C] In some cases this document imposes "MUST" and/or "SHOULD"
> requirements which deviate from a significant body of current practice
> at the time of this writing.  In such cases these requirements are
> imposed when experience indicates that following such requirements
> is likely to lead, in practice, to better interoperation, or
> smoother operation of the Internet email infrastructure.   Though
> this document does attempt to ensure that (fully or partially)
                                                                ^
                                                                conforming
> implementations of this specification will interoperate with
> (fully or partially) conforming implementations of its predecessors,
> it does not attempt to legitimize common deviations from those
> specifications, and it does impose new requirements.  Existing
                                                      ^
                                                      Some
> implementations of SMTP will need some changes if they are to
> conform to this new specification.
> 

Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 09:29:23 -0400

> But I see little point in repeating the 2119 text in full.

as Dan pointed out, there is language in 2119 (specifically 
section 6) that over-constrains use of 2119.  since 2119
was published it is apparent that there are valid reasons
to use 2119 keywords that  are not "actually required for 
interoperation or to limit behavior which has potential 
for causing harm" ... especially when we base try to define
conformance to the specification strictly in terms of 
these keywords.

the normal workaround (until 2119 is revised) is for a
document to provide its own definitions of MUST/SHOULD/etc.
I suppose we could try referencing 2119 with a disclaimer
that section 6 does not apply...and see if that gets by IESG.
if we wanted to try this I'd strongly recommend that someone 
approach the author of 2119 first and ask him in person about it.

one thing that worries me about defining conformance in this way:
do we have confidence that adhering to the MUSTs SHOULDs etc
is sufficient to call an implementation conforming, in the
sense that we believe that the implementation will function
properly and interoperate with other implementations?
or are there enough things in the document that are not specified
in this way?

somehow I don't like the idea that "if the document doesn't
say MUST or SHOULD about a particular thing, it's not needed
for conformance, so we can disregard it"

Keith

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Jul 2000 14:40:41 -0000

Keith Moore writes:
> section 6) that over-constrains use of 2119.

That's not what I said.

As far as I'm concerned, the biggest flaw in section 6 of RFC 2119 is
that IETF documents in general _aren't_ required to follow it.

If you're violating section 6, chances are excellent that you're
violating United States antitrust law. In the words of the Federal Trade
Commission, standards must not impose ``construction requirements'' in
place of ``performance requirements.''

I understand that the smtpupd editor refuses to follow section 6. I was
trying to stay away from this issue, so that we could focus on bringing
the document's definition of ``SHOULD'' in line with what the readers
will expect. Copying the RFC 2119 text is the easiest way to do this.

---Dan

P.S. Why hasn't Newman declared that your message will be ignored? See
section 4 of his ``procedures.''

---

From: "Bart Schaefer" <[email-masked]>
Date: Fri, 28 Jul 2000 15:49:01 +0000

On Jul 28,  9:29am, Keith Moore wrote:
} Subject: Re: 2nd suggested revision for MUST/SHOULD
}
} one thing that worries me about defining conformance in this way:
} do we have confidence that adhering to the MUSTs SHOULDs etc
} is sufficient to call an implementation conforming, in the
} sense that we believe that the implementation will function
} properly and interoperate with other implementations?

I'd also like to point out that the "SHOULD"/"MAY" problem with X.1.9(iv)
still exists if these definitions of fully v. partially conforming are
attached to the definitions from 2119.  I believe we either need to use
2119 without such additions, or else include something along the lines
of my suggested "MAY" text as well.

I think that each of the suggested revisions is more clearly stated than
the text presently in 2.3.

-- 
Bart Schaefer                                                   Zanshin
http://www.well.com/user/barts                   http://www.zanshin.com

---

From: Keith Moore <[email-masked]>
Date: Fri, 28 Jul 2000 12:30:54 -0400

> > section 6) that over-constrains use of 2119.

I stand corrected.  sorry to put words in your mouth.

Keith

---

From: [email-masked] (Kai Henningsen)
Date: 29 Jul 2000 13:42:00 +0200

> place of ``performance requirements.''

From my memory, the "not following 6" issue is *not* about construction  
requirements, it's about performance requirements not (directly) on the  
wire - stuff like certain configuration options must (whould, whatever) be  
available, for example.

As far as I can tell, construction requirements have generally been  
avoided as much as humanly possible by drums.

And of course, while I suspect most participants of deums actually agree  
with this particular requirement, it is also quite obvious to me that the  
US law in question is completely irrelevant here - Internet standards  
cannot be subject to US legislation. The UN might have a case.

MfG Kai