Re: SHOULD and RECOMMENDED

[Hector Santos]

Hi,

I think there are far too many debates on RFC2119 semantics and I think 
it can be reduced by focusing on better technical protocol writing 
skills.  A simple recommendation to always include (if possible) a 
Minimum Requirements table or section can go a long way in removing 
ambiguity.  Some of these docs are just too verbose and design concepts 
too spread out to extract all that is needed. Too easy to have semantic 
conflicts. Things are missed or fall thru the crack.


It should be possible to have an automated RFC parser that pulls and 
extracts the minimum protocol framework configuration. Its been done 
since the 80s with automated configuration/fitting tools.  It can be 
done with IETF protocols as well, perhaps if only to extract a minimum 
requirements table.


Personally, I think RECOMMENDED is closer to a SHOULD than MAY. IMV, a 
SHOULD is a RECOMMENDED, yet still OPTIONAL mode of operation.  So I 
agree the term RECOMMENDED can be used to inform readers what is the 
preferred mode of operation. I personally view it as a DEFAULT ON 
condition where it is programmed for local policy to decide, but it is 
ON out of the box because of the RECOMMENDED mode of operation.  A MAY 
on the other hand is also possible recommendation, but I see it as a 
DEFAULT OFF or ON condition.


   [o] SHOULD OPTION
   [_] MAY OPTION

None of this is concrete of cause, but it should be easier if authors 
were better skilled in writing more precise technical requirements 
outlines to reduce the ambiguity and debates.


--
HLS




On 6/22/2013 1:28 PM, Barry Leiba wrote:


I believe that it would be wise to discourage
"RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
"SHOULD NOT" unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.



A fine suggestion, with which I agree.

Barry

Re: SHOULD and RECOMMENDED

[Dave Crocker]

On 6/22/2013 10:28 AM, Barry Leiba wrote:

I believe that it would be wise to discourage
"RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
"SHOULD NOT" unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.


A fine suggestion, with which I agree.



For normative vocabulary, synonyms are sinful.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

They are not synonyms

Lets go back to 1980:

Implementations SHOULD support DES
vs
RECOMMENDED encryption algorithms: DES, IDEA


There are many specifications that specify crypto algorithms that should
not. JOSE and XML Signature should not have required algorithms or even
SHOULD language. The protocols that are built on the specifications are
where the normative language belongs.




On Sun, Jun 23, 2013 at 6:00 PM, Dave Crocker  wrote:

> On 6/22/2013 10:28 AM, Barry Leiba wrote:
>
>> I believe that it would be wise to discourage
>> "RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
>> "SHOULD NOT" unless they are clearly necessary to avoid awkward
>> sentences and the non-A/S intent is completely clear.
>>
>>
>> A fine suggestion, with which I agree.
>>
>
>
> For normative vocabulary, synonyms are sinful.
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>



-- 
Website: http://hallambaker.com/

Re: SHOULD and RECOMMENDED

[John C Klensin]

--On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
 wrote:

> They are not synonyms
> 
> Lets go back to 1980:
> 
> Implementations SHOULD support DES
> vs
> RECOMMENDED encryption algorithms: DES, IDEA

Actually, that is the point.  The usage above, although much
earlier, reflects the Protocol Specification/ Applicability
Statement split rather well.

But 2119's language makes the two terms substitutable for and
equivalent to each other, which is about as close a definition
of "synonyms" as one can find.  What I said is that making them
equivalent was probably a mistake and that treating them that
was should be discouraged. Others expressed agreement with that
assessment.  

Personally, I don't think the problem is severe enough to reopen
2119.  If others disagree and believe that 2119 is generating
enough problems to be worth an update, I await a draft.

So, other than quibbling about the "synonym" issue -- not
generally, which no one has claimed, but in context with 2119--
are you disagreeing and, if so, about what?

   john

Re: SHOULD and RECOMMENDED

[Hector Santos]

On 6/24/2013 8:39 AM, John C Klensin wrote:

--On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
 wrote:


They are not synonyms

Lets go back to 1980:

Implementations SHOULD support DES
vs
RECOMMENDED encryption algorithms: DES, IDEA


Actually, that is the point.  The usage above, although much
earlier, reflects the Protocol Specification/ Applicability
Statement split rather well.

But 2119's language makes the two terms substitutable for and
equivalent to each other, which is about as close a definition
of "synonyms" as one can find.  What I said is that making them
equivalent was probably a mistake and that treating them that
was should be discouraged. Others expressed agreement with that
assessment.

Personally, I don't think the problem is severe enough to reopen
2119.  If others disagree and believe that 2119 is generating
enough problems to be worth an update, I await a draft.

So, other than quibbling about the "synonym" issue -- not
generally, which no one has claimed, but in context with 2119--
are you disagreeing and, if so, about what?

john


In my view, a SHOULD is just a highly RECOMMENDED mode of operation, the 
preferred mode, the mode that SHOULD be enabled out of the box.


The conflicts I see is whether the usage of a SHOULD means it really is 
a MUST be implemented as described and the exception is when there is no 
other alternative available. A common reference is use EHLO first, 
fallback to HELO.


What is often forgotten is the ON/OFF configuration aspect. So even if 
there is a MUST implement SHOULD thinking, the question is whether there 
is an allowance to disable or turn off the feature, i.e. can an SMTP 
server disable EHLO and operate in pure RFC821 (STD10) mode?  The answer 
to the question is yes, its possible, and therefore all implementations 
MUST be ready in operate in SMTP (821) mode FIRST, ESMTP mode second.


I think the dilemma is that we have new integration needs and in some 
cases, one protocol or set of integrated protocols simple works better 
when a traditional optional technology i.e. SMTP extension, is used. So 
there is a mindset, it seems, a SHOULD is really a MUST and only under 
extreme situations,  the alternative can be used, if presented.


--
HLS

RE: SHOULD and RECOMMENDED

[Michael Thornburgh]

my feeling and belief is that RFC 2119 only gives SHOULD and RECOMMENDED the 
same normative requirement level, but that it does not override or change the 
distinct meanings of these words in English.  sentences using each of these 
terms have different meanings in English, even when those sentences appear in 
RFCs.

-michael thornburgh


> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John 
> C Klensin
> Sent: Monday, June 24, 2013 5:40 AM 
> 
> --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
>  wrote:
> 
> > They are not synonyms
> >
> > Lets go back to 1980:
> >
> > Implementations SHOULD support DES
> > vs
> > RECOMMENDED encryption algorithms: DES, IDEA
> 
> Actually, that is the point.  The usage above, although much
> earlier, reflects the Protocol Specification/ Applicability
> Statement split rather well.
> 
> But 2119's language makes the two terms substitutable for and
> equivalent to each other, which is about as close a definition
> of "synonyms" as one can find.  What I said is that making them
> equivalent was probably a mistake and that treating them that
> was should be discouraged. Others expressed agreement with that
> assessment.
> 
> Personally, I don't think the problem is severe enough to reopen
> 2119.  If others disagree and believe that 2119 is generating
> enough problems to be worth an update, I await a draft.
> 
> So, other than quibbling about the "synonym" issue -- not
> generally, which no one has claimed, but in context with 2119--
> are you disagreeing and, if so, about what?
> 
>john
> 

Re: SHOULD and RECOMMENDED

[Peter Saint-Andre]

On 6/24/13 1:47 PM, Michael Thornburgh wrote:
> my feeling and belief is that RFC 2119 only gives SHOULD and
> RECOMMENDED the same normative requirement level, but that it does
> not override or change the distinct meanings of these words in
> English.  sentences using each of these terms have different meanings
> in English, even when those sentences appear in RFCs.

I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

The mistake I was attempting to avoid here was concluding that RECOMMENDED 
should not be used.

It does have a necessary use that is distinct from SHOULD.

Given the number of citations it gets, I am sure someone will be willing to 
volunteer to do a revision if Scott Bradner is not interested.


On Jun 24, 2013, at 8:39 AM, John C Klensin  wrote:

> 
> 
> --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker
>  wrote:
> 
>> They are not synonyms
>> 
>> Lets go back to 1980:
>> 
>> Implementations SHOULD support DES
>> vs
>> RECOMMENDED encryption algorithms: DES, IDEA
> 
> Actually, that is the point.  The usage above, although much
> earlier, reflects the Protocol Specification/ Applicability
> Statement split rather well.
> 
> But 2119's language makes the two terms substitutable for and
> equivalent to each other, which is about as close a definition
> of "synonyms" as one can find.  What I said is that making them
> equivalent was probably a mistake and that treating them that
> was should be discouraged. Others expressed agreement with that
> assessment.  
> 
> Personally, I don't think the problem is severe enough to reopen
> 2119.  If others disagree and believe that 2119 is generating
> enough problems to be worth an update, I await a draft.
> 
> So, other than quibbling about the "synonym" issue -- not
> generally, which no one has claimed, but in context with 2119--
> are you disagreeing and, if so, about what?
> 
>   john
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: SHOULD and RECOMMENDED

[Dave Crocker]

On 6/24/2013 12:52 PM, Peter Saint-Andre wrote:

I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.



I suspect you are wrong...

In your implication that there is /any/ meaningful distinction made by 
native English speakers when reading an RFC...


For the times I've seen the different words used normatively in RFC, I 
have not discerned any semantic difference.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: SHOULD and RECOMMENDED

[Yoav Nir]

On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre  wrote:

> On 6/24/13 1:47 PM, Michael Thornburgh wrote:
>> my feeling and belief is that RFC 2119 only gives SHOULD and
>> RECOMMENDED the same normative requirement level, but that it does
>> not override or change the distinct meanings of these words in
>> English.  sentences using each of these terms have different meanings
>> in English, even when those sentences appear in RFCs.
> 
> I expect that the subtle differences between these words are lost on
> non-native speakers, and even most native speakers, of English. I'd be
> genuinely curious to hear that you think the distinct meanings are.
> 

"It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at 
least 4 minutes before the SA is to be deleted, to facilitate the user entering 
credentials in time."

"The implementation SHOULD send the AUTH_LIFETIME notification at least 4 
minutes before the SA is to be deleted, to facilitate the user entering 
credentials in time."

- What are the subtle differences in meaning between these two sentences?

- Would an implementation written by a native speaker be any different 
depending on which of the above sentences was in the RFC?

Yoav

Re: SHOULD and RECOMMENDED

[Peter Saint-Andre]

On 6/24/13 2:08 PM, Dave Crocker wrote:
> On 6/24/2013 12:52 PM, Peter Saint-Andre wrote:
>> I expect that the subtle differences between these words are lost on
>> non-native speakers, and even most native speakers, of English. I'd be
>> genuinely curious to hear that you think the distinct meanings are.
> 
> 
> I suspect you are wrong...
> 
> In your implication that there is /any/ meaningful distinction made by
> native English speakers when reading an RFC...
> 
> For the times I've seen the different words used normatively in RFC, I
> have not discerned any semantic difference.

I agree. (It would have been better for me to say "subtle differences,
if any".)

I'm open to an argument that in standard English "should" has a shade of
obligation and "recommended" has a shade of suggestion, but in practice
(especially in RFCs) those shades are lost.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: SHOULD and RECOMMENDED

[Melinda Shore]

On 6/24/13 12:18 PM, Yoav Nir wrote:
> - What are the subtle differences in meaning between these two
> sentences?

I think "I recommend" is rather clearly different from "you should,"
in terms of strength and (in the case of normative text) obligation.
I don't think that "recommend" is useful in the context of an RFC,
may be confusing and a bit subtle, and is probably best avoided.

Melinda

Re: SHOULD and RECOMMENDED

[Alia Atlas]

I read SHOULD and RECOMMENDED as different.

SHOULD is how a implementation ought to behave unless there are special
circumstances (deployment, additional functionality, better idea).  MUST
says that there are no circumstances special enough to change the behavior.

RECOMMENDED is closer to a Best Current Practice (BCP); so I might write
"It is RECOMMENDED that the network-converged timer have a minimum value of
2 seconds."  but in 10 years, maybe it'll only take 2 microseconds - so
that'll become a bad recommendation!

Alia


On Mon, Jun 24, 2013 at 4:23 PM, Melinda Shore wrote:

> On 6/24/13 12:18 PM, Yoav Nir wrote:
> > - What are the subtle differences in meaning between these two
> > sentences?
>
> I think "I recommend" is rather clearly different from "you should,"
> in terms of strength and (in the case of normative text) obligation.
> I don't think that "recommend" is useful in the context of an RFC,
> may be confusing and a bit subtle, and is probably best avoided.
>
> Melinda
>

Re: SHOULD and RECOMMENDED

[John C Klensin]

--On Monday, June 24, 2013 16:28 -0400 Alia Atlas
 wrote:

> I read SHOULD and RECOMMENDED as different.
> 
> SHOULD is how a implementation ought to behave unless there
> are special circumstances (deployment, additional
> functionality, better idea).  MUST says that there are no
> circumstances special enough to change the behavior.
> 
> RECOMMENDED is closer to a Best Current Practice (BCP); so I
> might write "It is RECOMMENDED that the network-converged
> timer have a minimum value of 2 seconds."  but in 10 years,
> maybe it'll only take 2 microseconds - so that'll become a bad
> recommendation!

And that, again, is close to the distinction that a reasonable
person might read into 2026.  But not into 2119 which appears
(at least to me) to make them fully-substitutable alternatives.

The distinction doesn't make the comments made by Peter, Dave,
or others any less valid.  If we told ourselves that readers
should (lower case) infer conformance statements from SHOULD and
applicability ones from RECOMMENDED... well, we would be pretty
delusional.

   john

Re: SHOULD and RECOMMENDED

[Bradner, Scott]

while I like to take credit for the good things in RFC 2119 (and disclaim the 
bad things) - the
term RECOMMENDED (good or bad)  comes from RFC 1122 

basically I copied the definition section from RFC 1122 for the 1st version of 
what became RFC 2119.
(see http://www.sobco.com/ids/draft-bradner-key-words-00.txt) 

based on mailing list discussion I produced two revisions of the ID (mostly to 
add guidance on usage)
http://www.sobco.com/ids/draft-bradner-key-words-01.txt
and
http://www.sobco.com/ids/draft-bradner-key-words-02.txt

the 02 version is what was approved by the IESG as RFC 2119

all of the above is to say that I can not help in this discussion about the 
difference between SHOULD & 
RECOMMENDED other than the fact they represent  different parts of speech

maybe Bob Braden has an idea since I do find  not a usage of RECOMMENDED in the 
RFC series before RFC 1122

Scott

On Jun 24, 2013, at 4:38 PM, John C Klensin  wrote:

> 
> 
> --On Monday, June 24, 2013 16:28 -0400 Alia Atlas
>  wrote:
> 
>> I read SHOULD and RECOMMENDED as different.
>> 
>> SHOULD is how a implementation ought to behave unless there
>> are special circumstances (deployment, additional
>> functionality, better idea).  MUST says that there are no
>> circumstances special enough to change the behavior.
>> 
>> RECOMMENDED is closer to a Best Current Practice (BCP); so I
>> might write "It is RECOMMENDED that the network-converged
>> timer have a minimum value of 2 seconds."  but in 10 years,
>> maybe it'll only take 2 microseconds - so that'll become a bad
>> recommendation!
> 
> And that, again, is close to the distinction that a reasonable
> person might read into 2026.  But not into 2119 which appears
> (at least to me) to make them fully-substitutable alternatives.
> 
> The distinction doesn't make the comments made by Peter, Dave,
> or others any less valid.  If we told ourselves that readers
> should (lower case) infer conformance statements from SHOULD and
> applicability ones from RECOMMENDED... well, we would be pretty
> delusional.
> 
>   john
> 
> 

Re: SHOULD and RECOMMENDED

[Dave Crocker]

On 6/24/2013 1:23 PM, Melinda Shore wrote:

I think "I recommend" is rather clearly different from "you should,"
in terms of strength and (in the case of normative text) obligation.
I don't think that "recommend" is useful in the context of an RFC,
may be confusing and a bit subtle, and is probably best avoided.



A number of the notes have offered personal views about the differences 
between the two words.  No doubt each of us could offer such comments. 
And perhaps some of us might even offer similar meanings.


Unfortunately, the ability of one person to impart their own semantic 
distinction is irrelevant to the current discussion, which is about 
normative language used for global standards that are read by widely and 
wildly different people around the world, with extreme differences in 
English language skills.


This is technical specification, not literature.  Subtlety and nuance -- 
especially of a linguistic nature -- is wholly inappropriate.


Just as we find simpler technology propagates better across the 
Internet, so does simpler specification language.


MAY/SHOULD/MUST has proved simple and sufficient.  Any gradations beyond 
that have demonstrated no utility for IETF specifications.


Hell, we still debate the differences of just /those/ 3 words...

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: SHOULD and RECOMMENDED

[Brian E Carpenter]

On 25/06/2013 08:38, John C Klensin wrote:
> 
> --On Monday, June 24, 2013 16:28 -0400 Alia Atlas
>  wrote:
> 
>> I read SHOULD and RECOMMENDED as different.
>>
>> SHOULD is how a implementation ought to behave unless there
>> are special circumstances (deployment, additional
>> functionality, better idea).  MUST says that there are no
>> circumstances special enough to change the behavior.
>>
>> RECOMMENDED is closer to a Best Current Practice (BCP); so I
>> might write "It is RECOMMENDED that the network-converged
>> timer have a minimum value of 2 seconds."  but in 10 years,
>> maybe it'll only take 2 microseconds - so that'll become a bad
>> recommendation!
> 
> And that, again, is close to the distinction that a reasonable
> person might read into 2026.  But not into 2119 which appears
> (at least to me) to make them fully-substitutable alternatives.
> 
> The distinction doesn't make the comments made by Peter, Dave,
> or others any less valid.  If we told ourselves that readers
> should (lower case) infer conformance statements from SHOULD and
> applicability ones from RECOMMENDED... well, we would be pretty
> delusional.

Also, issuing 2119bis with a subtle difference between the two
would create a horrible problem of interpretation for all existing
documents (including numerous documents from other SDOs) that
explicitly cite 2119. This has ramifications that make my head hurt.

   Brian

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

RECOMMENDED is a strong suggestion that the implementation may override at
the discretion of the implementer. SHOULD is normative.

So the first tells me that I can make up my own mind, the second says that
I should give a reason if I don't comply.


On Mon, Jun 24, 2013 at 4:18 PM, Yoav Nir  wrote:

>
> On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre 
> wrote:
>
> > On 6/24/13 1:47 PM, Michael Thornburgh wrote:
> >> my feeling and belief is that RFC 2119 only gives SHOULD and
> >> RECOMMENDED the same normative requirement level, but that it does
> >> not override or change the distinct meanings of these words in
> >> English.  sentences using each of these terms have different meanings
> >> in English, even when those sentences appear in RFCs.
> >
> > I expect that the subtle differences between these words are lost on
> > non-native speakers, and even most native speakers, of English. I'd be
> > genuinely curious to hear that you think the distinct meanings are.
> >
>
> "It is RECOMMENDED that implementations send the AUTH_LIFETIME
> notification at least 4 minutes before the SA is to be deleted, to
> facilitate the user entering credentials in time."
>
> "The implementation SHOULD send the AUTH_LIFETIME notification at least 4
> minutes before the SA is to be deleted, to facilitate the user entering
> credentials in time."
>
> - What are the subtle differences in meaning between these two sentences?
>
> - Would an implementation written by a native speaker be any different
> depending on which of the above sentences was in the RFC?
>
> Yoav
>
>
>


-- 
Website: http://hallambaker.com/

Re: SHOULD and RECOMMENDED

[Dave Cridland]

On Tue, Jun 25, 2013 at 1:33 AM, Phillip Hallam-Baker wrote:

>
> RECOMMENDED is a strong suggestion that the implementation may override at
> the discretion of the implementer. SHOULD is normative.
>
>
Of course, they both mean the same, because the author has (one assumes)
explicitly said that it means what it says in RFC 2119. Applying your own
meanings to words used in specifications is never going to work, because
otherwise I could start waxing lyrical on what exactly a credential meant
(and in traditional spoken English, it relates to authorization rather than
authentication as here).

In ordinary English, without specific guidance as RFC 2119 gives, I'd
consider "should" and "must" as having virtually the same strength, and
"recommended" being far lower. "Should", however, is used for third parties
and also when a requirement has exceptions, conditions, and so on - it's
also used for general conditional statements, too, such as "I'd like that",
which really expands to "I should like that" rather than "I would like
that". Another case is that if I say "Phillip must have read RFC 2119",
I've made an incorrect statement if he hasn't, whereas if I say "Phillip
should have read RFC 2119", then it's clear Phillip would be the one at
fault.

Much of the problem with actual English in specifications comes from the
fact that specifications are written to tell people what something else
should do, and English as a language is more adept at telling you what you
must do, and ideally by using the imperative form instead.

So while I can write, "You must read RFC 2119. Do not attempt to derive
implied meaning not present in RFC 2119", I can only express a desire that
Phillip should do the same.

Dave.

Re: SHOULD and RECOMMENDED

[Martin Rex]

Phillip Hallam-Baker wrote:
>
> RECOMMENDED is a strong suggestion that the implementation may override at
> the discretion of the implementer. SHOULD is normative.
> 
> So the first tells me that I can make up my own mind, the second says that
> I should give a reason if I don't comply.

This is only half of the story.

PKIX (rfc5280) defines the concept of a "minimum requirements RP",
i.e. an implementation which implements only MUSTs, and potentially not
a single SHOULD.  Essentially, this waters down all SHOULDs to MAYs.

-Martin

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

I DO NOT agree that 2119 is the only source of consequence here.

Perhaps if I showed Dave Cridland an article on netiquete he could try to
be less patronizing. Unlike some here I do not regard the RFC series as
having divine inspiration.


Many other standards organizations use normative language. Though at this
point who is following whom is difficult to determine.

RECOMMENDED is a very useful term to have. Particularly when writing specs
for middleware.


The IETF document describing use of the term is WRONG it needs to be
corrected. Any corrections would only apply to new specs that reference the
new RFC.



On Tue, Jun 25, 2013 at 8:27 AM, Dave Cridland  wrote:

> On Tue, Jun 25, 2013 at 1:33 AM, Phillip Hallam-Baker wrote:
>
>>
>> RECOMMENDED is a strong suggestion that the implementation may override
>> at the discretion of the implementer. SHOULD is normative.
>>
>>
> Of course, they both mean the same, because the author has (one assumes)
> explicitly said that it means what it says in RFC 2119. Applying your own
> meanings to words used in specifications is never going to work, because
> otherwise I could start waxing lyrical on what exactly a credential meant
> (and in traditional spoken English, it relates to authorization rather than
> authentication as here).
>
> In ordinary English, without specific guidance as RFC 2119 gives, I'd
> consider "should" and "must" as having virtually the same strength, and
> "recommended" being far lower. "Should", however, is used for third parties
> and also when a requirement has exceptions, conditions, and so on - it's
> also used for general conditional statements, too, such as "I'd like that",
> which really expands to "I should like that" rather than "I would like
> that". Another case is that if I say "Phillip must have read RFC 2119",
> I've made an incorrect statement if he hasn't, whereas if I say "Phillip
> should have read RFC 2119", then it's clear Phillip would be the one at
> fault.
>
> Much of the problem with actual English in specifications comes from the
> fact that specifications are written to tell people what something else
> should do, and English as a language is more adept at telling you what you
> must do, and ideally by using the imperative form instead.
>
> So while I can write, "You must read RFC 2119. Do not attempt to derive
> implied meaning not present in RFC 2119", I can only express a desire that
> Phillip should do the same.
>
> Dave.
>



-- 
Website: http://hallambaker.com/

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

On Tue, Jun 25, 2013 at 8:31 AM, Martin Rex  wrote:

> Phillip Hallam-Baker wrote:
> >
> > RECOMMENDED is a strong suggestion that the implementation may override
> at
> > the discretion of the implementer. SHOULD is normative.
> >
> > So the first tells me that I can make up my own mind, the second says
> that
> > I should give a reason if I don't comply.
>
> This is only half of the story.
>
> PKIX (rfc5280) defines the concept of a "minimum requirements RP",
> i.e. an implementation which implements only MUSTs, and potentially not
> a single SHOULD.  Essentially, this waters down all SHOULDs to MAYs.
>

>From a minimum implementation point of view MAY, RECOMMENDED and SHOULD all
have the same effect. They are not identical from other points of view.

MAY tells the implementer that there is behavior that they are required to
accept from other implementations they interact with. So it creates an
implicit MUST NOT.

SHOULD tells the implementer that there is behavior that cannot be
compliance checked that is important.


I would like to see more clarity in IETF specs and the minimum use of MUST,
SHOULD and MAY since they all create compliance requirements.
Distinguishing RECOMMENDED from SHOULD properly would help here.


I suggest that if specs want to use RECOMMENDED and SHOULD as not being
synonyms that they follow the reference to 2119 with a statement explaining
the difference.




-- 
Website: http://hallambaker.com/

Re: SHOULD and RECOMMENDED

[Scott Brim]

On Tue, Jun 25, 2013 at 8:52 AM, Phillip Hallam-Baker  wrote:
> I DO NOT agree that 2119 is the only source of consequence here.

Sorry.  RFCs are not written in English, they are written in RFCish, a
language based in English but with modifications (specified in RFCs).
2119 overrides anything you might think you know about what words
mean.

Re: SHOULD and RECOMMENDED

[Dave Cridland]

Phillip Hallam-Baker wrote:


I DO NOT agree that 2119 is the only source of consequence here.

If a document explicitly states that the term "RECOMMENDED" is to be
interpreted as in RFC 2119, then that really is the only
interpretation, and RFC 2119 does then become the only source of
consequence. This is beyond personal opinions.





Perhaps if I showed Dave Cridland an article on netiquete he could try
to be less patronizing. Unlike some here I do not regard the RFC
series as having divine inspiration.



I'm not claiming it's the traditional meaning of the term, just that
RFCs do tend to be explicit in what they mean by it..

I've no idea how I'm being patronizing, but I'm certainly not claiming
any kind of divine inspiration for the RFCs. I'm merely suggesting
that if a document says "This word means X", we should accept that and
move on.







RECOMMENDED is a very useful term to have. Particularly when writing
specs for middleware.

That's an interesting debate to have, but it has no bearing on what
the term means in the context of documents citing RFC 2119.

For what it's worth, I entirely agree that a term with force somewhere
between MAY and SHOULD would be very useful in some cases, but in
general we can work around this, such as saying "implementations are
encouraged to use channel binding", or some such.







The IETF document describing use of the term is WRONG it needs to be
corrected. Any corrections would only apply to new specs that
reference the new RFC.



It's not wrong, it clearly gives a meaning to the term. That meaning
is not in line with the implications it might have if used in spoken
English, certainly, but it's clearly stated, and used in that sense as
far as I can tell.

Dave.


Sent with [inky: ]

Re: SHOULD and RECOMMENDED

[Doug Ewell]

Scott Brim  wrote:

> 2119 overrides anything you might think you know about what words
> mean.

and Dave Cridland  wrote:

> If a document explicitly states that the term "RECOMMENDED" is to
> be interpreted as in RFC 2119, then that really is the only
> interpretation, and RFC 2119 does then become the only source of
> consequence. This is beyond personal opinions.

Documents that intend these magic words to have their RFC 2119 meanings
include boilerplate text:

"The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in RFC 2119."

If a document wants to impart different meaning to one or more of the
words, wouldn't a simple list of the exceptions, immediately following
the boilerplate, solve the problem?

--
Doug Ewell | Thornton, CO, USA
http://ewellic.org | @DougEwell ­

Re: SHOULD and RECOMMENDED

[Hector Santos]

I want to know more what it translates to as a technical specification 
for CODING.   To me, it means this:


   o Authorization Lift Time
 [X] Send Notification
 Time to send: __4__ mins (default)


The problem as I experienced thus far is whether one MUST IMPLEMENT this 
protocol feature,in this case code for AUTH_LIFETIME and make it 
flexible with a default 4 mins timeout.


At the end of the day, this feature is not functionally described as a 
MUST protocol requirement, therefore as a product producer I have two 
design options:


  1) Don't implement, possible less feature than competitors.
 See if others implement it.

  2) Implement and make it optional as the UI shows above.

So I don't think its a really a language or native culture thing, its 
just poor functional/technical specification writing.  Of course, if one 
does not implement AUTH_LIFETIME and they later find out there are 
interoperability issues with other products in the market, then there is 
a "BUG" in the specification.  It may need to be fixed in a BIS as a 
MUST or maybe the products that failed when a peer did not support it, 
then its considered buggy because it read the above as a MUST.


I would like to see a focus to produce more protocol writing guidelines, 
outline examples and tips on how to best reduce the ambiguity.   I think 
the available RFC templates should include a new section:


   1.x Minimum Requirements

This should help writers focus on these type of issues for the multiple 
discipline readers out there.


--
HLS



On 6/24/2013 4:18 PM, Yoav Nir wrote:


On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre  wrote:


On 6/24/13 1:47 PM, Michael Thornburgh wrote:

my feeling and belief is that RFC 2119 only gives SHOULD and
RECOMMENDED the same normative requirement level, but that it does
not override or change the distinct meanings of these words in
English.  sentences using each of these terms have different meanings
in English, even when those sentences appear in RFCs.


I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.



"It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 
4 minutes before the SA is to be deleted, to facilitate the user entering credentials in 
time."

"The implementation SHOULD send the AUTH_LIFETIME notification at least 4 minutes 
before the SA is to be deleted, to facilitate the user entering credentials in time."

- What are the subtle differences in meaning between these two sentences?

- Would an implementation written by a native speaker be any different 
depending on which of the above sentences was in the RFC?

Yoav

Re: SHOULD and RECOMMENDED

[Hector Santos]

Sounds like an never ending loop. 2119 is an RFC too and thus written in 
"RFCish" as well.


To me, it only matters in terms of implementation - should we waste time 
and money on implementing a SHOULD/RECOMMENDED feature?  Is it required 
to be coded?  Can it be delayed, for version 2.0?  Is it really needed, 
competitively? Will something break if we don't add it?


A good example was the DKIM and BIT8MIME issue.

BIT8MIME is an SMTP extension, therefore NOT REQUIRED by SMTP servers to 
support it.


It was determined the conversion and translation recommendations in 
BIT8MIME helps DKIM function better with less integrity errors, 
therefore there was an argument that all SMTP servers MUST support 
BIT8MIME if they claim to support DKIM. There was an attempt to mandate 
this in DKIM-BIS:


SMTP Servers MUST support BIT8MIME.

This created an immediate, resounding uproar and negative response 
simply because not every SMTP server supported BIT8 MIME conversions. 
So it was changed back to:


SMTP Servers SHOULD support BIT8MIME.

This shows the growing integration design and requirements pressure we 
are in, especially with newer protocols that depend on other OPTIONAL 
protocols in order to function correctly.  The same is true with other 
things like international conversions and translations, all currently 
optional for the most part.


--

On 6/25/2013 10:08 AM, Scott Brim wrote:

On Tue, Jun 25, 2013 at 8:52 AM, Phillip Hallam-Baker  wrote:

I DO NOT agree that 2119 is the only source of consequence here.


Sorry.  RFCs are not written in English, they are written in RFCish, a
language based in English but with modifications (specified in RFCs).
2119 overrides anything you might think you know about what words
mean.

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

On Tue, Jun 25, 2013 at 11:51 AM, Doug Ewell  wrote:

> Scott Brim  wrote:
>
> > 2119 overrides anything you might think you know about what words
> > mean.
>

No, 2119 PURPORTs to do that. It can try but it probably isn't going to
succeed.

The purpose of RFCs is to communicate ideas. In ordinary language there is
a clear distinction between RECOMMENDED and SHOULD. There is a useful
distinction between them in the context of writing a standard.

There are in fact standards bodies apart from the IETF. I have always
interpreted 2119 the same way I interpret the RFC describing ASCII: it is
the local source of a convention that has been established collectively by
the standards organizations as a whole.

RFCs make local definitions all the time, that does not mean that an RFC is
free to make any definitions it chooses. For example:

White: The color that is seen in the absence of any light source whatsoever.


The point I was making is that RECOMMENDED is used with a distinct meaning
by a large fraction of the standards community and the IETF could benefit
from the same approach.


> and Dave Cridland  wrote:
>
> > If a document explicitly states that the term "RECOMMENDED" is to
> > be interpreted as in RFC 2119, then that really is the only
> > interpretation, and RFC 2119 does then become the only source of
> > consequence. This is beyond personal opinions.
>
> Documents that intend these magic words to have their RFC 2119 meanings
> include boilerplate text:
>
> "The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
> 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
> document are to be interpreted as described in RFC 2119."
>
> If a document wants to impart different meaning to one or more of the
> words, wouldn't a simple list of the exceptions, immediately following
> the boilerplate, solve the problem?
>

Since SHOULD and RECOMMENDED are treated as being strictly equivalent, it
seems to me that a document that uses the terms with distinct meanings that
are compatible with the 2119 use should say so.

If an implementer finds language of the form "Implementations SHOULD
support AES-128" I expect them to implement unless they have a good reason
not to.

If on the other hand the language is "RECOMMENDED algorithms: AES-128", I
expect them to take that as a warning signal that the basis for the
author's recommendation may be dependent on assumptions that may not hold
for a particular circumstance (e.g. Moores law continues to 2050 and we all
have heptaflop computing engines in our shoe.)


-- 
Website: http://hallambaker.com/

Re: SHOULD and RECOMMENDED

[Scott Brim]

On Tue, Jun 25, 2013 at 1:40 PM, Hector Santos  wrote:
> To me, it only matters in terms of implementation - should we waste time and
> money on implementing a SHOULD/RECOMMENDED feature?  Is it required to be
> coded?  Can it be delayed, for version 2.0?  Is it really needed,

Every vendor goes through that decision process.  Some operators make
SHOULDs required in their RFIs.  The IETF WG decides on what it feels
is a necessary level of interoperability and leaves the rest up to
them.  The IETF is not going to make decisions for you about things it
thinks are optional.

> competitively? Will something break if we don't add it?

If leaving it out breaks something that's required, then it should be
a MUST and you should (not must) say so.

Re: SHOULD and RECOMMENDED

[Yoav Nir]

Those sentences are here without the context given in RFC 4478. But that RFC is 
entirely about AUTH_LIFETIME, so if you're not sending it, you're just not 
implementing the RFC. 

Those sentences are about the timing of sending the message. Upon receipt of 
the message, the client software prompts the user for credentials, so we'd like 
to have that message sent soon enough so that a human user will have enough 
time to enter the credentials before the SA expires. So is specifying 4 minutes 
a "recommendation" or a "should-level requirement"?

IMO, in normal English this would be a recommendation. But in an RFC this is 
also a should-level requirement, one that a particular implementation might 
ignore (if the implementers know that the client in this case has no human 
user). In terms of code, you do the same thing with both sentences: you make 
sure your VPN gateway sends AUTH_LIFETIME at least 4 minutes before the SA is 
scheduled to expire. You might even do 15 if you find out that your users tend 
to take coffee breaks that last that long.


On Jun 25, 2013, at 8:13 PM, Hector Santos  wrote:

> I want to know more what it translates to as a technical specification for 
> CODING.   To me, it means this:
> 
>   o Authorization Lift Time
> [X] Send Notification
> Time to send: __4__ mins (default)
> 
> 
> The problem as I experienced thus far is whether one MUST IMPLEMENT this 
> protocol feature,in this case code for AUTH_LIFETIME and make it flexible 
> with a default 4 mins timeout.
> 
> At the end of the day, this feature is not functionally described as a MUST 
> protocol requirement, therefore as a product producer I have two design 
> options:
> 
>  1) Don't implement, possible less feature than competitors.
> See if others implement it.
> 
>  2) Implement and make it optional as the UI shows above.
> 
> So I don't think its a really a language or native culture thing, its just 
> poor functional/technical specification writing.  Of course, if one does not 
> implement AUTH_LIFETIME and they later find out there are interoperability 
> issues with other products in the market, then there is a "BUG" in the 
> specification.  It may need to be fixed in a BIS as a MUST or maybe the 
> products that failed when a peer did not support it, then its considered 
> buggy because it read the above as a MUST.
> 
> I would like to see a focus to produce more protocol writing guidelines, 
> outline examples and tips on how to best reduce the ambiguity.   I think the 
> available RFC templates should include a new section:
> 
>   1.x Minimum Requirements
> 
> This should help writers focus on these type of issues for the multiple 
> discipline readers out there.
> 
> --
> HLS
> 
> 
> 
> On 6/24/2013 4:18 PM, Yoav Nir wrote:
>> 
>> On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre  wrote:
>> 
>>> On 6/24/13 1:47 PM, Michael Thornburgh wrote:
>>>> my feeling and belief is that RFC 2119 only gives SHOULD and
>>>> RECOMMENDED the same normative requirement level, but that it does
>>>> not override or change the distinct meanings of these words in
>>>> English.  sentences using each of these terms have different meanings
>>>> in English, even when those sentences appear in RFCs.
>>> 
>>> I expect that the subtle differences between these words are lost on
>>> non-native speakers, and even most native speakers, of English. I'd be
>>> genuinely curious to hear that you think the distinct meanings are.
>>> 
>> 
>> "It is RECOMMENDED that implementations send the AUTH_LIFETIME notification 
>> at least 4 minutes before the SA is to be deleted, to facilitate the user 
>> entering credentials in time."
>> 
>> "The implementation SHOULD send the AUTH_LIFETIME notification at least 4 
>> minutes before the SA is to be deleted, to facilitate the user entering 
>> credentials in time."
>> 
>> - What are the subtle differences in meaning between these two sentences?
>> 
>> - Would an implementation written by a native speaker be any different 
>> depending on which of the above sentences was in the RFC?
>> 
>> Yoav
>> 
>> 

Re: SHOULD and RECOMMENDED

[Brian E Carpenter]

On 26/06/2013 05:58, Phillip Hallam-Baker wrote:
> On Tue, Jun 25, 2013 at 11:51 AM, Doug Ewell  wrote:
> 
>> Scott Brim  wrote:
>>
>>> 2119 overrides anything you might think you know about what words
>>> mean.
> 
> No, 2119 PURPORTs to do that. It can try but it probably isn't going to
> succeed.
> 
> The purpose of RFCs is to communicate ideas. In ordinary language there is
> a clear distinction between RECOMMENDED and SHOULD. There is a useful
> distinction between them in the context of writing a standard.
> 
> There are in fact standards bodies apart from the IETF. 

Yes, and when they explicitly cite RFC 2119, they accept the definitions
therein, one of which equates SHOULD and RECOMMENDED. You can dislike
that equation but it becomes an axiom. They both mean "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."

If you don't like this, it's easy to avoid: don't cite RFC 2119.

Brian

Re: SHOULD and RECOMMENDED

[Hector Santos]

Good point, timeouts are important and we know in practice, they vary 
for many reasons, and in many cases, there are different functional 
needs depending on human versus automated interfaces/handlers.


Nonetheless, I always prefer being specific when all possible.  I still 
believe this is universal and global and readers will "get it." Give 
them the benefit of the doubt. Its a matter of having better written 
specifications and understanding there are multiple disciplined readers 
and conflicts between administrators (sysops) vs developers (coders).


IMO, in this case because it is related to a required time property 
(including the idea that it could be infinite, forever, zero, -1 or 
otherwise ), it would be up to the protocol specification to clearly 
define what are the boundary conditions for success and failure;


The implementator MUST offer a reasonable timeout value for the
AUTH_LIFETIME notification. A RECOMMENDED timeout value is
4 minutes.  Anything less risk X, Y and Z and anything more has
shown to cause this or that.

etc, "Being specific is Terrific"

(Note, I am not aware of RFC 4478. I am provided general input because 
this is a general problem.  Maybe its too late for existing specs but 
future specifications can benefit from better guidelines.)


--
HLS



On 6/25/2013 4:41 PM, Yoav Nir wrote:

Those sentences are here without the context given in RFC 4478. But that RFC is 
entirely about AUTH_LIFETIME, so if you're not sending it, you're just not 
implementing the RFC.

Those sentences are about the timing of sending the message. Upon receipt of the message, the 
client software prompts the user for credentials, so we'd like to have that message sent soon 
enough so that a human user will have enough time to enter the credentials before the SA expires. 
So is specifying 4 minutes a "recommendation" or a "should-level requirement"?

IMO, in normal English this would be a recommendation. But in an RFC this is 
also a should-level requirement, one that a particular implementation might 
ignore (if the implementers know that the client in this case has no human 
user). In terms of code, you do the same thing with both sentences: you make 
sure your VPN gateway sends AUTH_LIFETIME at least 4 minutes before the SA is 
scheduled to expire. You might even do 15 if you find out that your users tend 
to take coffee breaks that last that long.


On Jun 25, 2013, at 8:13 PM, Hector Santos  wrote:


I want to know more what it translates to as a technical specification for 
CODING.   To me, it means this:

   o Authorization Lift Time
 [X] Send Notification
 Time to send: __4__ mins (default)


The problem as I experienced thus far is whether one MUST IMPLEMENT this 
protocol feature,in this case code for AUTH_LIFETIME and make it flexible with 
a default 4 mins timeout.

At the end of the day, this feature is not functionally described as a MUST 
protocol requirement, therefore as a product producer I have two design options:

  1) Don't implement, possible less feature than competitors.
 See if others implement it.

  2) Implement and make it optional as the UI shows above.

So I don't think its a really a language or native culture thing, its just poor 
functional/technical specification writing.  Of course, if one does not implement 
AUTH_LIFETIME and they later find out there are interoperability issues with other 
products in the market, then there is a "BUG" in the specification.  It may 
need to be fixed in a BIS as a MUST or maybe the products that failed when a peer did not 
support it, then its considered buggy because it read the above as a MUST.

I would like to see a focus to produce more protocol writing guidelines, 
outline examples and tips on how to best reduce the ambiguity.   I think the 
available RFC templates should include a new section:

   1.x Minimum Requirements

This should help writers focus on these type of issues for the multiple 
discipline readers out there.

--
HLS



On 6/24/2013 4:18 PM, Yoav Nir wrote:


On Jun 24, 2013, at 10:52 PM, Peter Saint-Andre  wrote:


On 6/24/13 1:47 PM, Michael Thornburgh wrote:

my feeling and belief is that RFC 2119 only gives SHOULD and
RECOMMENDED the same normative requirement level, but that it does
not override or change the distinct meanings of these words in
English.  sentences using each of these terms have different meanings
in English, even when those sentences appear in RFCs.


I expect that the subtle differences between these words are lost on
non-native speakers, and even most native speakers, of English. I'd be
genuinely curious to hear that you think the distinct meanings are.



"It is RECOMMENDED that implementations send the AUTH_LIFETIME notification at least 
4 minutes before the SA is to be deleted, to facilitate the user entering credentials in 
time."

"The implementation SH

Re: SHOULD and RECOMMENDED

[Doug Barton]

In English as it is commonly spoken "recommended," and "should" do 
indeed mean different things. Arguably it's unfortunate that 2119 
conflated them, but that's the landscape we're living in.


So if the question is, "How do we improve the normative language in 
RFCs?" we should probably be thinking along the lines of giving more 
details about the conditions related to the things should/recommended 
apply to. I think it was Brian that said a while back that there should 
never be a SHOULD in a doc without an accompanied "unless ..." that 
spells out when the SHOULD can safely not be followed. It's not hard to 
imagine a similar guideline for "RECOMMENDED, because ..." that explains 
why something is recommended, and ideally also spells out the 
consequences if it is not done.


The idea being that 10 years from now a document can stand on its own as 
the repository of information about the topic it describes without 
having to fall back on WG discussions, anecdotes, etc. Another way to 
look at it is to ask the question, "Does this document have everything 
necessary for someone to create an interoperable implementation from 
scratch?"


thoughts?

Doug

Re: SHOULD and RECOMMENDED

[Phillip Hallam-Baker]

+1

I think SHOULD and RECOMMENDED should both be used when there is a strong
suggestion that implementations comply with the following statement unless
there are reasons not to.

Where I think it is time to go beyond 2119 is that we can distinguish two
circumstances:

SHOULD is the preferred term when the reasons are objective, e.g. certain
platforms don't support green flidgets.

RECOMMENDED is the preferred term when the reasons are subjective or
subject to change. I can recommend AES but only on the basis of current
knowledge.


I really don't see hotlinks from other institutions to RFC 2119 as any
problem at all. RFC 2119 will not change even if the IETF updates it. A
document that references 2119 for normative language will continue to do so
unless reissued with a new RFC number.



On Wed, Jun 26, 2013 at 8:26 PM, Doug Barton  wrote:

> In English as it is commonly spoken "recommended," and "should" do indeed
> mean different things. Arguably it's unfortunate that 2119 conflated them,
> but that's the landscape we're living in.
>
> So if the question is, "How do we improve the normative language in RFCs?"
> we should probably be thinking along the lines of giving more details about
> the conditions related to the things should/recommended apply to. I think
> it was Brian that said a while back that there should never be a SHOULD in
> a doc without an accompanied "unless ..." that spells out when the SHOULD
> can safely not be followed. It's not hard to imagine a similar guideline
> for "RECOMMENDED, because ..." that explains why something is recommended,
> and ideally also spells out the consequences if it is not done.
>
> The idea being that 10 years from now a document can stand on its own as
> the repository of information about the topic it describes without having
> to fall back on WG discussions, anecdotes, etc. Another way to look at it
> is to ask the question, "Does this document have everything necessary for
> someone to create an interoperable implementation from scratch?"
>
> thoughts?
>
> Doug
>



-- 
Website: http://hallambaker.com/

SHOULD and RECOMMENDED (was: Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07)

[John C Klensin]

--On Saturday, June 22, 2013 10:34 -0400 Barry Leiba
 wrote:

> In RFC 2119, "SHOULD" and "RECOMMENDED" are synonymous
> (they're just covering different parts of speech; they fit
> differently into sentences).  Changing "SHOULD" to
> "RECOMMENDED" (and, of course, rewording the sentences
> accordingly) doesn't affect Ben's comments on the points.

FWIW, 

While the above is certainly true, I believe that synonym
relationship is one of the poorer ideas in 2119.  The problem is
that 2026 assigns a rather different interpretation to
"recommended" in the context of Applicability Statements (A/Ss).
That was relatively unimportant when we were almost never using
explicit Applicability Statements but, now that we are doing so
again, I believe that it would be wise to discourage
"RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
"SHOULD NOT" unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.

   john

Re: SHOULD and RECOMMENDED (was: Re: Gen-ART LC Review of draft-thornburgh-adobe-rtmfp-07)

[Barry Leiba]

>
> I believe that it would be wise to discourage
> "RECOMMENDED" and "NOT RECOMMENDED" as synonyms for "SHOULD" and
> "SHOULD NOT" unless they are clearly necessary to avoid awkward
> sentences and the non-A/S intent is completely clear.
>

A fine suggestion, with which I agree.

Barry