Re: [Rfcplusplus] problems and solutions

[Brian E Carpenter <[e-mail]>]

Yes. I put a rough and ready list of problems in
https://tools.ietf.org/html/draft-carpenter-request-for-comments-00#section-2
and I would expect a BOF to start by considering a complete problem
set and prioritising before trying to pick a solution.

https://www.brainyquote.com/quotes/h_l_mencken_129796


Regards
   Brian

On 20/06/2018 08:16, Bob Hinden wrote:
> 
>> On Jun 19, 2018, at 11:15 AM, Andrew G. Malis <[e-mail]> wrote:
>>
>> Needless to say, +1!
> 
> I also agree, and would support clearer boilerplate.  This would do no harm, as compared to what is proposed in the BOF description that I think would create more confusion.
> 
> Bob
> 
>>
>> Cheers,
>> Andy
>>
>>
>> On Tue, Jun 19, 2018 at 2:07 PM, Peter Saint-Andre <[e-mail]> wrote:
>> (Just joined the list, sorry about the new thread.)
>>
>> The primary problem folks here have pointed to is confusion among people
>> who write RFPs. Both Barry and Adam provided entertaining anecdotes, the
>> likes of which I've seen as well. However, those problems were solved
>> fairly easily by educating the customer (less easily, perhaps, in large
>> organizations with poor communication - what's new?).
>>
>> To judge the proposal, could the proposers provide a basic cost-benefit
>> analysis, preferably including data and an accounting of risks?
>>
>> As to solutions, Andrew Malis proposed some clearer boilerplate text at
>> the top of each document. Some years ago, we added text like this to
>> specs in the XMPP Standards Foundation's XEP series, and it helped to
>> educate people who were confused about document status. [1]
>>
>> Peter
>>
>> [1] Here is the text we use at the XSF...
>>
>> For a Final XEP (like an Internet Standard RFC), green text stating:
>>
>> NOTICE: The protocol defined herein is a Final Standard of the XMPP
>> Standards Foundation and can be considered a stable technology for
>> implementation and deployment.
>>
>> example: https://xmpp.org/extensions/xep-0030.html
>>
>> For a Draft XEP (like a Proposed Standard RFC), green text stating:
>>
>> NOTICE: The protocol defined herein is a Draft Standard of the XMPP
>> Standards Foundation. Implementations are encouraged and the protocol is
>> appropriate for deployment in production systems, but some changes to
>> the protocol are possible before it becomes a Final Standard.
>>
>> example: https://xmpp.org/extensions/xep-0176.html
>>
>> For an Experimental XEP (like an Internet-Draft), red text stating:
>>
>> WARNING: This Standards-Track document is Experimental. Publication as
>> an XMPP Extension Protocol does not imply approval of this proposal by
>> the XMPP Standards Foundation. Implementation of the protocol described
>> herein is encouraged in exploratory implementations, but production
>> systems are advised to carefully consider whether it is appropriate to
>> deploy implementations of this protocol before it advances to a status
>> of Draft.
>>
>> example: https://xmpp.org/extensions/xep-0400.html
>>
>> For a Humorous XEP (published on April Fool's Day), green text stating:
>>
>> NOTICE: This document is Humorous. It MAY provide amusement but SHOULD
>> NOT be taken seriously.
>>
>> example: https://xmpp.org/extensions/xep-0076.html
>>
>> And so on...
>>
>>
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rfcplusplus
>>
>>
>> _______________________________________________
>> Rfcplusplus mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rfcplusplus
> 
> 
> 
> _______________________________________________
> Rfcplusplus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rfcplusplus
>