Re: 2119bis

In the perfect written technical specification, if you pulled out all
the SHOULDs, the protocol still survives.  But if a required
functionality breaks down, then it wasn't well written.

On 8/30/11, Eric Burger <eburger(_at_)standardstrack(_dot_)com> wrote:
> Can you give an example of where a dangling SHOULD makes sense?  Most often
> I see something like:
>       SHOULD implement security
> meaning
>       SHOULD implement security, unless you do not feel like it or are in an
> authoritarian regime that bans security
>
>
> On Aug 30, 2011, at 12:11 PM, Keith Moore wrote:
>
> > On Aug 30, 2011, at 12:06 PM, Marc Petit-Huguenin wrote:
> >
> > > The meaning of SHOULD is clear for the authors (it "mean[s] 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."), the problem is that some implementers use a
> > > different
> > > meaning (I do not have to implement this if it is inconvenient or
> > > difficult for
> > > me to implement), vendors another one (SHOULD gave us the right to not
> > > implement
> > > it).  I even read somewhere, perhaps on this list, about a vendor that
> > > rejected
> > > any bug report against a SHOULD.  Conditional MUST, in my opinion, does
> > > not have
> > > this problem.
> > But conditional MUST has other problems, namely that you have to enumerate
> > the exceptions for the MUST, and that's not always practical.
> >
> > Implementors who think that SHOULD gives them a free pass to avoid
> > implementing something that's needed to interoperate are misreading 2119.
> > But document editors should avoid using SHOULD for cases where failure to
> > implement the requirement will result in interoperability failure.
> >
> > I could see maybe posting an erratum or a brief update to 2119, but I
> > think that reopening that document in general is a Very bad Idea.  And for
> > existing documents that misuse SHOULD, the appropriate thing to do is to
> > update those documents or post errata to those documents, rather than try
> > to retroactively change the meaning of the keywords in those documents.
> >
> > Keith
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www.ietf.org/mailman/listinfo/ietf

-- 
hls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf