Subject: [Rfced-future] Document formats - not on this list?

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 29 Aug 2020 10:00:12 +0100

Hi,

Fascinating though the discussion of document formats is, perhaps having
that discussion on [email-masked] would free this list up for
discussion of the thing we are supposed to be talking about.

Not playing "list police", just saying.

Best,
Adrian

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 29 Aug 2020 11:34:00 +0200

> discussion of the thing we are supposed to be talking about.

Right. For the part here: What would have been the role of various players in addressing the problem that has been discussed in this thread?  Here’s what an RSE might have done.

(1) Sensing that there is a rather expensive (in expert-hours) disconnect between the RFC production process and the authoring process.  (Well, OK, many people did sense a problem here, but weren’t stating it this way — see the subject of this message...)

(2) Owning the problem and starting to work on an outline for improving the connection to the authoring process.  Looking at the way this is handled in other places.  Consulting with the community on what our experiences are.  Deriving objectives.

(3) Addressing the problem.  Not necessary by throwing out the baby and keeping the bathwater.  Or even starting a heavy, top-down program for fixing this.  Maybe soliciting (and guiding, integrating) some bottom-up initiatives.  Making sure these are aware about the objectives formed in (2).

(4) Facilitating the initiatives by getting communication between themselves and with the community going.  Maybe do kick off some specific projects on re-focusing some existing approaches [example here: SVG].

(5) Profit

Grüße, Carsten

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Aug 2020 12:33:37 -0700

On Sat, Aug 29, 2020 at 2:34 AM Carsten Bormann <[email-masked]> wrote:

> Right. For the part here: What would have been the role of various players
> in addressing the problem that has been discussed in this thread?  Here’s
> what an RSE might have done.
>
> (1) Sensing that there is a rather expensive (in expert-hours) disconnect
> between the RFC production process and the authoring process.  (Well, OK,
> many people did sense a problem here, but weren’t stating it this way — see
> the subject of this message...)
>
> (2) Owning the problem and starting to work on an outline for improving
> the connection to the authoring process.  Looking at the way this is
> handled in other places.  Consulting with the community on what our
> experiences are.  Deriving objectives.
>
> (3) Addressing the problem.  Not necessary by throwing out the baby and
> keeping the bathwater.  Or even starting a heavy, top-down program for
> fixing this.  Maybe soliciting (and guiding, integrating) some bottom-up
> initiatives.  Making sure these are aware about the objectives formed in
> (2).
>
> (4) Facilitating the initiatives by getting communication between
> themselves and with the community going.  Maybe do kick off some specific
> projects on re-focusing some existing approaches [example here: SVG].
>
> (5) Profit
>

This is indeed an interesting hypothetical. However, I would note that in
this discussion we've touched on a number of other SDOs who have different
toolchains:

- Word-based [per John, ANSI, ISO, IEEE]
- HTML-based [W3C, WHATWG, TC39]
- LaTeX [C++]

It seems natural to ask which, if any, of those SDOs engaged an external
expert to assist in selecting/designing those toolchains? Do we know?

-Ekr

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 29 Aug 2020 23:01:21 +0200

On 2020-08-29, at 21:33, Eric Rescorla <[email-masked]> wrote:
> 
> I would note that in this discussion we've touched on a number of other SDOs who have different toolchains:
> 
> It seems natural to ask which, if any, of those SDOs engaged an external expert to assist in selecting/designing those toolchains? Do we know?

Well, I don’t.  
(But a German professor can talk about any subject, so I’ll do that.)

Some of these organizations are rooted in international diplomacy (e.g., ISO, IEC, ITU-T), so they usually have some rather formal rules for document generation that are imposed on all their documents (these are usually somewhat mixed up with their standardization processes).  I’m sure there will have been some interaction between the ISO editor, however they are called these days, and JTC1/SC22/WG21 before they were allowed to do their own toolchain for the C++ standards.

ISO also is a publishing house (at least that is the main way they and their member organizations make revenue), so the publishing side will be more than “an external expert”.  Apart from their own standards development, they need a process to take in specifications such as MS-OOX and (as an example from our world, say) OCF specifications and publish them as ISO/IEC standards.

IEEE is a professional organization that also makes a large amount of its revenue by serving as a publishing house, so again there will be some staff that will be guiding that side professionally.

ANSI is mostly a franchising brand (and the US national member of ISO) and not really an SDO.  I’m sure INCITS and the other SDOs running under that brand are getting some guidance on publishing from the franchise owner.

I haven’t worked on IEEE or ANSI (INCITS) documents, so I don’t know much.

ECMA is trying to play in the same league, but my contacts with that organization diminished with the age of daisy-wheel printers [1].  Add OASIS to that tier.

The other organizations are not really making use of publishing.  
They essentially are a website.  

The IETF could go for “being a website”, too.  Or for making its work available in a mix of publishing and “a website” (which, of course, is already true to some extent, e.g. the IANA registries).  The urge for such a move may be the 800-pound gorilla that is deliberately outside of the scope of the effort this mailing list is for.

Grüße, Carsten

[1]: http://ecma-international.org/publications/files/ECMA-ST/ECMA-35,%204th%20Edition,%20March%201985.pdf

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Aug 2020 14:10:27 -0700

On Sat, Aug 29, 2020 at 2:01 PM Carsten Bormann <[email-masked]> wrote:

>
> The other organizations [WHATWG, W3C -- EKR] are not really making use of
> publishing.

I'm not sure what distinction you are making here between "publishing" and
"web site". They "publish" their documents on the Web. What characteristics
do you believe distinguish these two?

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Aug 2020 11:59:04 +1200

On 30-Aug-20 09:10, Eric Rescorla wrote:
> 
> 
> On Sat, Aug 29, 2020 at 2:01 PM Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     The other organizations [WHATWG, W3C -- EKR] are not really making use of publishing. 
> I'm not sure what distinction you are making here between "publishing" and "web site". They "publish" their documents on the Web. What characteristics do you believe distinguish these two?

Precisely "web site". If the Web no longer existed they would have no reason to exist either. I think the IETF (and for that matter ANSI, ITU, ISO, IEEE, C++...) might still exist. So we want a format that can be retrofitted to papyrus or whatever comes next after the Web.

   Brian

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Aug 2020 18:47:24 -0700

On Sat, Aug 29, 2020 at 4:59 PM Brian E Carpenter <
[email-masked]> wrote:

> > I'm not sure what distinction you are making here between "publishing"
> and "web site". They "publish" their documents on the Web. What
> characteristics do you believe distinguish these two?
>
> Precisely "web site". If the Web no longer existed they would have no
> reason to exist either. I think the IETF (and for that matter ANSI, ITU,
> ISO, IEEE, C++...) might still exist. So we want a format that can be
> retrofitted to papyrus or whatever comes next after the Web.
>

Well, this is not true for TC39 (JavaScript is used widely outside the
Web), and yet it uses the same publication structure.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Sun, 30 Aug 2020 09:24:58 +0200

Eric,

Unless you and others are attempt to support an argument that effectively ends the  the RFC publication process as we know it, that tooling will need to evolve, taking into account input format, output format, and other factors that neither of us have thought about, and the discussion is at the wrong level.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Aug 2020 04:41:04 -0700

On Sun, Aug 30, 2020 at 12:25 AM Eliot Lear <[email-masked]> wrote:

> Eric,
>
> Unless you and others are attempt to support an argument that effectively
> ends the  the RFC publication process as we know it, that tooling will need
> to evolve, taking into account input format, output format, and other
> factors that neither of us have thought about, and the discussion is at the
> wrong level.
>

I agree that it's desirable for our tooling and processes to evolve. What I
am trying to do is understand the extent to which it is necessary to engage
external expertise in order for it to do so. To that end, it's quite
relevant to ask which of our peer organizations engaged such help in the
design of their formats and processes.

-Ekr