+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
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 thinki
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 unive
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.
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
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 th
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
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 r
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 feat
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 beco
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.
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
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 secon
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.
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 o
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
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 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, bett
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 probabl
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-ke
--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
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
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 t
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 meanin
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 wo
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 im
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 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 dif
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 sentenc
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, alth
--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 P
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 pr
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 s
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. Som
>
> 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
35 matches
Mail list logo
