- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 30 Jul 2013 22:19:53 +0200
- To: cowwoc <cowwoc@bbs.darktech.org>
- CC: ietf-http-wg@w3.org
On 2013-07-30 22:08, cowwoc wrote: > On 30/07/2013 2:59 PM, Julian Reschke wrote: >> On 2013-07-30 18:12, cowwoc wrote: >>> I understand this line of reasoning for MUST, but I fail to see the >>> logic for SHOULD which by definition (being optional) does not "impose a >> >> No, SHOULD is not "optional". MAY is optional. >> >>> particular method on implementers where the method is not required for >>> interoperability". >>> >>> Are you looking for a way to say "this can be implemented one many >>> ways, one approach is to X"? >> >> No, "ought to" means "should", we just want to avoid the confusion >> with a BCP14-SHOULD. >> >> Best regards, Julian > > My interpretation of "SHOULD" as defined by > http://tools.ietf.org/html/bcp14 is that it is a combination of "MAY" > and "RECOMMENDATION". Meaning, the reader is encouraged to do something, 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. ...so should is a recommendation. MAY allows something. > but may choose to do otherwise if understand the consequences of doing > so. The definition says nothing about the reasons for the recommendation > (whether they are related to interoperability or not). Again, from RFC 2119: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. > I argue that your (new) definition for "SHOULD" is not based on > bcp14. If you wish to use it in this manner, I recommend providing your > own definition which explicitly states that "SHOULD" relates to > interoperability concerns and "should"/"ought to" mean the same thing > but without reference to interoperability concerns. As it stands, the > current document is unnecessarily confusing. I believe we are using SHOULD exactly the way as described in Sections 3 and 6 of RFC 2119. Best regards, Julian
Received on Tuesday, 30 July 2013 20:20:23 UTC