Re: 2119bis

A fundamental fact is that the IETF RFC document models are for a 
multiple-disciplined environments of people, at least most are writing 
with a mix view of different audiences.    Not too many break it down 
to different functional vs technical specification levels.
A Manager, Docs, Help, Support, Admin person might read SHOULD 
different in how its applied than perhaps a software/author person in 
the finer details in the how things work or behave differently than 
what was interpreted at higher levels.
IMV, this is all about good software or component engineering methods, 
and if one wishes to follow a trend, take a look at industry efforts, 
such as with Microsoft SE efforts with Code Contracts which is to 
basically provide a meta language to make sure functional I/O 
interfaces are well defined especially with well defined exceptions.
Here is wikipedia's description of this growing direction with 
developers that increasingly need all the help they can get in an 
extreme complex integrated world of "Plug and Play" pieces:
    http://en.wikipedia.org/wiki/Design_by_contract

   The central idea of DbC is a metaphor on how elements of a
   software system collaborate with each other, on the basis of mutual
   obligations and benefits. The metaphor comes from business life, 
where
   a "client" and a "supplier" agree on a "contract" which defines for
   example that:

   o The supplier must provide a certain product (obligation) and
     is entitled  to expect that the client has paid its fee (benefit).

   o The client must pay the fee (obligation) and is entitled to get
     the product (benefit).

   o Both parties must satisfy certain obligations, such as laws and
     regulations, applying to all contracts.

Is there such an ideas for "IETF Standards Engineering & 
Implementation Contracts?"  I think that is what we are trying to do 
here with RFC2026, RFC2019 all along.
But to me, the only way you can even begin this, is for the author to 
first layout and for the reader to extract what are the minimum 
requirements of a RFC protocol specification - that is the first CODE 
CONTRACT anyone can even first thing about.
--



John C Klensin wrote:
> --On Tuesday, September 13, 2011 08:28 +1200 Brian E Carpenter
> <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
>
> > John,
> >
> > I don't share your confusion. I do feel that to be able to
> > construct reasonably pleasant sentences, we need both the verb
> > SHOULD and the adjectival participle RECOMMENDED, and their
> > negatives, in various circumstances.
> >
> > I could propose an alternative erratum, adding MANDATORY,
> > but I won't; it's NOT MANDATORY to increase confusion.
> Brian,
>
> I don't think this is worth pushing very hard, nor spending a
> lot of time on.  If Peter wants to approve the other (499)
> erratum in the name of editorial consistency, I will lose
> exactly zero sleep over it.
>
> However, as things have evolved, our goal is apparently to turn
> the terminology of 2026 and 2119 into very specific terms of art
> with clear boundaries.  Personally, I don't particularly like
> such efforts.  As you know from other discussions, I generally
> believe that trying to force our increasingly-complex protocols
> and protocol interactions into rigid categories (whether those
> are Proposed/ Draft/ Full, MUST/ SHOULD / MAY and their
> negations, or something else), presumably by the method of
> Procrustes because nothing else really works, does not serve us
> well.  But, if we are going to do it, then lists of synonyms and
> near-synonyms for those terms of art really don't help us.   
>
> Even if use of the specific terms sometimes leads to awkward
> sentence constructions, so does trying to avoid those terms when
> they are not appropriate.  I note that
> draft-hansen-nonkeywords-non2119 takes us into the realm of
> personifying protocols to the extent of talking about what they
> "need to" do, a construction that would have given the people
> who taught me --and probably you-- how to write at least a bad
> case of the creeps and possible outrage.
>
> So, again, if we really intend terms of art, rather than
> slightly-less-informal prose, I think we would be better off
> with one term per concept/category and living with it.  If we
> really intend slightly-less-informal prose --which is the way I
> took the intent of 2119 when it was first written (perhaps
> erroneously)-- then none of this discussion and the
> corresponding hair-splitting makes much difference and we should
> just make 2119 internally consistent and move on.
>
> YMMD.
>
>     john
>
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf