[usefor] Fwd: Re: Maturity level of NNTP and Netnews-related RFCs

Julien ÉLIE <julien@trigofacile.com> Fri, 06 January 2017 20:13 UTC

Return-Path: <julien@trigofacile.com>
X-Original-To: usefor@ietfa.amsl.com
Delivered-To: usefor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D152129E53 for <usefor@ietfa.amsl.com>; Fri, 6 Jan 2017 12:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp5wRvrVFAqN for <usefor@ietfa.amsl.com>; Fri, 6 Jan 2017 12:12:56 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr [80.12.242.131]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA8212961F for <usefor@ietf.org>; Fri, 6 Jan 2017 12:12:55 -0800 (PST)
Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d18 with ME id V8Cs1u00o17Lgi4038CtBD; Fri, 06 Jan 2017 21:12:53 +0100
X-ME-Helo: macbook-pro-de-julien-elie.home
X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg==
X-ME-Date: Fri, 06 Jan 2017 21:12:53 +0100
X-ME-IP: 92.170.5.52
References: <CAC4RtVBcuheLtqRsq6NAD7vy-gJDFtmFe9nh9Bge_ehvh301ow@mail.gmail.com>
To: ietf-nntp@lists.eyrie.org, usefor@ietf.org
From: Julien ÉLIE <julien@trigofacile.com>
Organization: TrigoFACILE -- http://www.trigofacile.com/
X-Forwarded-Message-Id: <CAC4RtVBcuheLtqRsq6NAD7vy-gJDFtmFe9nh9Bge_ehvh301ow@mail.gmail.com>
Message-ID: <75413cb0-08d2-b388-cbb0-31ff52fa5bc2@trigofacile.com>
Date: Fri, 06 Jan 2017 21:12:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CAC4RtVBcuheLtqRsq6NAD7vy-gJDFtmFe9nh9Bge_ehvh301ow@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/usefor/8IrsxhHgyKWlbTUcosC5ylwtW7A>
Subject: [usefor] Fwd: Re: Maturity level of NNTP and Netnews-related RFCs
X-BeenThere: usefor@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of usefor issues." <usefor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/usefor>, <mailto:usefor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/usefor/>
List-Post: <mailto:usefor@ietf.org>
List-Help: <mailto:usefor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/usefor>, <mailto:usefor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2017 20:13:00 -0000

Hi all,

FYI, the Draft Standard status disappeared with RFC 6410.  I proposed 
the IESG to have a look at advancing NNTP and article format RFCs from 
Proposed Standards to Internet Standards.
Unfortunately, for that to happen, normative references also have to be 
at the Internet Standard maturity level.  Which means that we notably 
have to wait for the MIME RFCs 2045 and 2047 to be Internet Standards 
before attempting to make NNTP and article format RFCs be Internet 
Standards.
And naturally, the IESG prefer SMTP and message format (RFCs 5321 and 
5322) to be Internet Standards before other RFCs linked to MIME.  This 
is totally understandable.

See you in a few years :)

-- 
Julien ÉLIE


-------- Message transféré --------
Sujet : Re: [dispatch] Maturity level of NNTP and Netnews-related RFCs
Date : Thu, 29 Dec 2016 18:34:07 -0500
De : Barry Leiba
Pour : Julien ÉLIE

> I think that RFCs related to NNTP and Netnews can be good candidates to
> advance from Proposed Standards to Internet Standards.

One snag here has traditionally been that there are lots of
prerequisites (normative references) that are still at PS.  The major
ones here are the MIME specs (2045 and 2047) and base64 (4648).

One possible solution to that is to invoke RFC 3967 and say that these
are reasonable downrefs because they're stable and mature... but 3967
is clear that in such a case, using downrefs is not the right answer,
and instead the downrefs should be progressed first.

To that end, there've been a couple of attempts to start pushing the
whole batch of SMTP (RFC 5321), message format (RFC 5322), MIME (RFCs
2045 thru 2049), and several others up to IS, enabling others batches
such as NNTP to go afterward.  See the aborted YAM working group for
one such attempt.

RFCs 5321 and 5322 are really the linchpins for this; we'd need to
start with those.

Barry


> NNTP
>   - RFC 3977 "Network News Transfer Protocol (NNTP)"
>   - RFC 4642 "Using TLS with NNTP"
>   - RFC 4643 "NNTP Extension for Authentication"
>   - RFC 4644 "NNTP Extension for Streaming Feeds"
>   - RFC 6048 "NNTP Additions to LIST Command"
>
> Netnews Article Format
>   - RFC 5536 "Netnews Article Format"
>   - RFC 5537 "Netnews Architecture and Protocols"
>
> Netnews URI Schemes
>   - RFC 5538 "The 'news' and 'nntp' URI Schemes"
>
>
>
> Are obsolete RFCs also candidates to Internet Standards?  (They once were
> widely-implemented standards at their time; I mean RFCs 850, 977, 1036,
> 1849.)
>
>
>
> Regarding the criteria given in Section 2.2 of RFC 6410 "Reducing the
> Standards Track to Two Maturity Levels":
>
> (1) Examples of two independent interoperating implementations with
> widespread deployment and successful operational experience:
>
> Examples of news servers implementing NNTPv2 (RFC 3977) and related
> extensions:
> o INN (InterNetNews) https://www.eyrie.org/~eagle/software/inn/
> o private news servers like Giganews (news.giganews.com)
>
> Examples of news clients implementing NNTPv2 (RFC 3977) and related
> extensions:
> o tin http://www.tin.org/
> o Gnus, the Emacs newsreader http://www.gnus.org/
> o Python library https://docs.python.org/3/library/nntplib.html
>
>
> (2) There are no errata against the specification that would cause a new
> implementation to fail to interoperate with deployed ones.
>
> Hmmm, maybe:
> o erratum 4468 in RFC 5537? (but I am unsure it is an interoperability
> failure; non-compliant messages sent by ancient versions of a few news
> clients are rejected by compliant news servers)
> o erratum 4708 in RFC 5538? (very minor)
>
> Though RFC 3977 has lots of errata, I don't think they would cause
> interoperability failures.  They should be considered more than wording
> improvements and consistency than interoperability failures.
>
>
> (3) There are no unused features in the specification that greatly increase
> implementation complexity.
>
> Not that I am aware of.
>
>
> (4) If the technology required to implement the specification requires
> patented or otherwise controlled technology, then the set of implementations
> must demonstrate at least two independent, separate and successful uses of
> the licensing process.
>
> Not applicable.
>
>
>
>
> Could you please tell me if my proposal to make the above RFCs as Internet
> Standards is receivable, and if that is the case, how to proceed?
>
> Thanks,
>
> --
> Julien ÉLIE
>
> « I had some words with my wife, and she had some paragraphs with
>   me. » (Sigmund Freud)