Subject: [Rfced-future] Some more summary points

From: Nevil Brownlee <[email-masked]>
Date: Mon, 27 Apr 2020 16:41:26 +1200

Hi all:
Here are a few more points for this list to consider ...

Need for RSE to have publishing experience?
  Proposed changes to RFC Series - do other publications do anything
similar?

How could we get feedback from users of the RFC Series?
  For example, could we find a University to conduct some research on this?
  How do researchers/developers/IPs/etc actually find out about Standards?

Independence of RSE?
  RSE serves all four Streams, we need to make sure that changes proposed
    by one Stream don't cause problems for any other Streams,

How should proposals for changes in the series be handled?
  I like Brian's idea of using the rfc-interest list to discuss these,
  with (my idea) the RSE acting like a "WG Chair" to monitor discussion,
  determine consensus, and document any agreed changes.

Continuing development of xml2rfc?
  Our 'new format' uses xml for it's canonical form, text, html and pdf
    versions are generated from the xml.
  The specifications for xml2rfc v3 (RFCs 7990 to 7990) were developed
    by a Design Team led by the RSE.
  Development of tools for v3 was done by the IETF Tools Team.
    The RFC Publication Centre started using them from about mid-2019,
    and the Tools folk have been working on problems as they arose.
    On the rfc-interest list there was discussion about this; it seems
    to me that it's time we started work on a definitive description
    of rfc2xml v3bis, so that we have a clear statement that open-source
    developers could work with.  This would be a good initial project
    for a new RSE (who will clearly need to be xml/html/etc.)

Cheers, Nevil
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Apr 2020 08:54:27 -0400

Thanks Nevil.  I find all of these interesting, and they all need answers.

Currently, the RSE is a liaison to the IETF Tools Team to coordinate thinks associated with xml2rfc and related tools.

Russ

> On Apr 27, 2020, at 12:41 AM, Nevil Brownlee <[email-masked]> wrote:
> 
> Hi all:
>   Proposed changes to RFC Series - do other publications do anything similar?
> 
>   determine consensus, and document any agreed changes..
>

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2020 13:37:27 -0400

In article <CACOFP=[email-masked]> you write:
>    developers could work with. ...

Julian and I are working on that now.  The first step is to document
the considerable difference between v3 and the XML that xml2rfc
currently accepts.

R's,
John

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Apr 2020 15:42:06 -0400

> On Apr 27, 2020, at 1:37 PM, John Levine <[email-masked]> wrote:
> 

Isn't that already in the expired draft-levkowetz-xml2rfc-v3-implementation-notes?

The recent updates may have added more things...

Russ

---

From: "John R. Levine" <[email-masked]>
Date: 27 Apr 2020 15:54:24 -0400

> Isn't that already in the expired draft-levkowetz-xml2rfc-v3-implementation-notes?

Not even close.  I'm encouraging Henrik to update that, too.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Apr 2020 05:34:14 +0200

On 27.04.2020 21:42, Russ Housley wrote:
> ...

It's good that this document exists, but it's a collection of:

- bug reports,

- description of new elements (partly incomplete, partly controversial),

- ideas.

It also lacks concrete descriptions of how this affects the other specs
(HTML, preptool, etc).

Finally, we also need to align all of this with the RFC style guide.

Best regards, Julian

---

From: Larry Masinter <[email-masked]>
Date: Mon, 27 Apr 2020 21:03:00 -0700

> > How could we get feedback from users of the RFC Series?

I think the "other SDOs" should  be a priority
for several additional reasons
*  There are areas of overlap where the entire suite of standards 
 used by any implementation cross multiple SDOs
* There are areas of overlap when there isn't clarity about scope
  and 'jurisdiction', and specs diverging further over time [1]
* There is the problems of  versioning and normative references
   between different series.
* They have similar audiences for specs and ideas
    for how to address them; we can compare notes.
 
For the web I'd ask W3C (process committee), WHATWG,
Maybe ECMA (for JavaScript), ISO, Unicode Consortium,
IEEE, others?

I'd suggest inviting a discussion through liaisons or directly.

--
https://LarryMasinter.net   https://going-remote.info 
*The particular case I have in mind is the divergence between
   RFC series specs and standards vs the URL "Living Standard".
   https://tools.ietf.org/html/draft-ruby-url-problem-01