Subject: [Rfced-future] My hard constraints

From: "Martin Thomson" <[email-masked]>
Date: Wed, 26 Aug 2020 12:22:05 +1000

On tricky problems we often do this little dance where no one says what they really want.   I think that it is important to be clear on what aspects of proposals are important as opposed to those that are either consequences of other decisions, arbitrary, or soft preferences.  So let me touch on three points of contention:

1. where strategy happens

For me, my overriding goal is to define a system whereby substantive strategy decisions are both discussed and resolved in a public forum.  From this, I derive two hard objections to the drafts that Mike has so helpfully published:

* no body with closed membership

* no tenured, employed, or contracted "leader"

Requirements that meetings be public are not sufficient to achieve this goal.  IAB and IESG meetings are also routinely public, but the only places where true engagement occurs is at plenaries, which is inadequate.

The latter applies, but to a far lesser extent to Brian's formulation of the Advisor role.  Conferring any amount of authority as part of employment/contract has - in my experience - produced bad outcomes.

2. how strategy is overseen

I have less of a strong preference regarding the body that acts as a process backstop.  I chose the IAB primarily because I saw no good alternative and it was a small change.

I specifically avoided suggesting a new body on the basis that this seemed excessive, and it creates yet another point in the system with closed membership.  I also anticipated John's concerns about the ISOC Board; they are a fine second backstop for the entire IETF process, but this case seems like an imposition.  I hope that the reasons not to choose the IESG don't need to be listed.

3. where strategy is documented

I have no real objection to the creation of a new stream, but note that the function of stream manager for that stream creates another position of authority that an individual fills.  That said, adopting an open process might be sufficient to avoid problems.

FWIW, though I've heard that publishing series maintenance documents on the IAB stream was considered to be a burden, in my time there I saw no evidence that the (lightweight) IAB approval procedures were a genuine problem.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Aug 2020 04:17:01 +0100

Hiya,

A clarifying question below...

On 26/08/2020 03:22, Martin Thomson wrote:
> For me, my overriding goal is to define a system whereby substantive
> strategy decisions are both discussed and resolved in a public forum.
> From this, I derive two hard objections to the drafts that Mike has
> so helpfully published:
> 

I kinda get that, though your terminology is a bit
odd, e.g. the membership of the LLC board or IAB
are both closed though anyone can volunteer in the
nomcom process for (almost all of) those seats.

> * no tenured, employed, or contracted "leader"
I do not get that. Can you say how you conclude that "discussed/resolved
in public" implies the above? I
don't see it myself TBH.

Ta,
S.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 26 Aug 2020 19:45:46 +1000

> nomcom process for (almost all of) those seats.

Yes.  I'm most concerned about placing any decision-making authority in such a body.  At least as far as those things in scope for this work are concerned.  We could likely do better with IAB, IESG, or Trust in addition, but those are not bodies under examination.

> in public" implies the above? I don't see it myself TBH.

Any authority vested in an individual (perceived or otherwise) presents the ultimate opportunity for deliberations and decisions to occur without public discourse.  Whether we as a community tolerate "I thought about it" any more than "we discussed it" is the ultimate decider, of course.  Given that we have far better alternatives than these options, I'd rather pursue those.

And as I think I've said before, longevity is grounded in culture (broken as ours seems to be in so many shameful ways, I might readily concede), not as a result of placing our faith in champions or heroes.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 26 Aug 2020 11:07:28 -0700

Martin,

> On Aug 26, 2020, at 2:45 AM, Martin Thomson <[email-masked]> wrote:
> 

How is this different from the current IETF Executive Director?    Seems to me that is setup in the way you describe.

Bob

> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Aug 2020 13:54:50 -0500

> How is this different from the current IETF Executive Director?    Seems to me that is setup in the way you describe.

I'm not sure how useful it is to tease apart how corporate governance 
differs (both legally and functionally) from document publication, but 
this question seems like a distraction from the topic at hand.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Aug 2020 14:16:44 +1200

> this question seems like a distraction from the topic at hand.

I certainly can't speak for Martin, but he and I do seem to agree that there
is a big divide between specified and contracted-out services, and strategic
and policy choices. Specified and contracted-out services fit well with
the LLC and Exec D model; after all, that's what the LLC was designed for.
But questions like <imaginary>"Should we use MS Word as the only tool for
preparing RFCs?"</imaginary> are not ones for the LLC Board or the Exec D.

The old RSE role was a bit ambiguous from this point of view, and IMHO
remains so in draft-stjohns-rfced-rseb. My solution to that is to make
the role clearly advisory; Martin's is to scrap it.

   Brian

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Aug 2020 22:21:54 -0500

> the role clearly advisory; Martin's is to scrap it.

I agree that this ambiguity is Bad, with a big B. I don't have strong 
feelings about the two options you describe here, but I think the 
approach likely to yield the best result isn't "let's assume there is a 
position here and then define what they do" as much as "let's figure out 
what the things that need to get done are, figure out who does them, and 
add some new role if and only if there is a clear gap."

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Aug 2020 15:41:44 +1200

> add some new role if and only if there is a clear gap."

Asked and answered in my draft:
"Much of the strategy will be concerned with the technical needs of the streams or with other matters that protocol engineers are competent to discuss. However, some matters will arise that are questions of technical editing, publishing, archiving, etc. Protocol engineers cannot be assumed to have the necessary expertise for these topics. Therefore, an outside RFC Series Advisor (RSA) is needed."
I have to say that this reflects my experience as a member of the existing RFC Series Advisory Group over a number of years. We have areas of ignorance, for which we need expert advice. 

    Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 28 Aug 2020 09:30:58 +1000

> the role clearly advisory; Martin's is to scrap it.

I would characterize it as the difference between a permanent role vs. an ad hoc or occasional role.  I'm not saying that advice isn't necessary, just not as part of a permanent fixture.  Consequently, that means not making that role structural.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Aug 2020 19:58:28 -0400

One of the benefits I see in the permanent role is taht we (as with most 
skilled individuals) tend to not see what we do not know.  Having 
someone permanently part of the process to remind us of the publishing 
perspective seems very useful.

Yours,
Joel

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Aug 2020 20:03:46 -0400

On Aug 27, 2020, at 7:58 PM, Joel M. Halpern <[email-masked]> wrote:
> One of the benefits I see in the permanent role is taht we (as with most skilled individuals) tend to not see what we do not know.  Having someone permanently part of the process to remind us of the publishing perspective seems very useful.

There is no such thing as a permanent role—people change jobs, die, etc. I think your basic point, that we want some longevity and institutional knowledge in this role, is valid, and I support it, but whatever is being accomplished with this role needs to survive the person who takes it on leaving.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Aug 2020 20:23:56 -0400

Fair enough Ted.  Should we use "persistent" rather than "permanent"?
I was reacting to the alternative of "hire when needed" that I 
understand Martin to be proposing.

Yours,
Joel

On 8/27/2020 8:03 PM, Ted Lemon wrote:
> On Aug 27, 2020, at 7:58 PM, Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> One of the benefits I see in the permanent role is taht we (as with 
>> most skilled individuals) tend to not see what we do not know.  Having 
> There is no such thing as a permanent role—people change jobs, die, etc. 
> I think your basic point, that we want some longevity and institutional 
> knowledge in this role, is valid, and I support it, but whatever is 
> being accomplished with this role needs to survive the person who takes 
> it on leaving.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Aug 2020 21:00:46 -0400

On Aug 27, 2020, at 8:23 PM, Joel M. Halpern <[email-masked]> wrote:
> I was reacting to the alternative of "hire when needed" that I understand Martin to be proposing.

I think that’s good, but I think it’s worth emphasizing that continuity is important in transition, not just while an individual is on staff.

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Aug 2020 20:13:08 -0500

> understand Martin to be proposing. 

I'm not Martin, but I'm reading his suggestion more as "specific 
designated person on paid retainer, who bills hours when called upon" 
rather than "hire when needed."  I think the former makes a lot of sense 
(and is consistent with how companies treat, e.g., external counsel), 
while I agree with you that the latter would be difficult to make work.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2020 15:25:30 +1200

> while I agree with you that the latter would be difficult to make work.
I'm not seeing much of a gap between what I wrote ("The RSA will operate
under a part-time professional services contract with the LLC...") and what
you're suggesting here. However, from practical experience in the RSAG
I think we'd need such advice more or less continually. Issues where the
RFC production people need advice come up all the time.

Full context at
https://tools.ietf.org/html/draft-carpenter-rfced-model-00#section-8
and comments most welcome.

    Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 28 Aug 2020 15:38:49 +1200

> On 28/08/2020, at 3:25 PM, Brian E Carpenter <[email-masked]> wrote:

> However, from practical experience in the RSAG

Can I just tease this out a bit more.  From my limited exposure to the process, the majority of the work/fuss is about such things as "I want a bulleted list of contributors written RTL inside a table cell inside the acknowledgements section and right-aligned with a gap in this SVG artwork" (I’m exaggerating, but not by much).  It is not clear to me if this requires a publishing expert, a community process to manage an ever more sophisticated style guide and underlying schema/tools, or someone who is very good at saying ’no’.  Is this the sort of thing you had in mind when you talk about continual advice or is it something different?

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2020 16:02:09 +1200

On 28-Aug-20 15:38, Jay Daley wrote:
> 
> 
>> On 28/08/2020, at 3:25 PM, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 

I'm not sure I'm the best person to ask. John Levine has the most recent experience; I've been out of the loop since IETF 106 due to COVID and timezones. The kind of issues I recall that are not really IT or line management questions were, for example, whether or not to start assigning DOIs to RFCs, and some years before that whether to get an ISSN number. Those were visible 'big ticket' issues but we always seemed to have some such questions come up at RSAG lunch meetings, and there was no question that the expert in the room was the RSE. Most of the rest of us didn't know what we didn't know.

There's no doubt that for several years the V3 format issues took up a large part of the meeting time and I think we're agreed that this isn't really part of what we're discussing now.

Hope this helps a little.

     Brian

---

From: Jay Daley <[email-masked]>
Date: Fri, 28 Aug 2020 16:34:28 +1200

> On 28/08/2020, at 4:02 PM, Brian E Carpenter <[email-masked]> wrote:
> 

While I can see that’s the sort of thing we need an expert for I would imagine that the advice is to the community not the RPC as the RPC doesn’t have authority to make those kinds of changes. I can also see that there would be some implementation advice required after something like that is decided but nothing that meets the bar of “continual”.  Am I missing something?
> There's no doubt that for several years the V3 format issues took up a large part of the meeting time and I think we're agreed that this isn't really part of what we're discussing now.

As I understand it, the style->XML->output chain is so tightly connected that most changes affect at least two if not three of those parts and that’s where the bulk of the work is, not the big ticket items above. 

It would indeed be helpful to get some current data about the nature of the “continual” work to see what skills are needed to support that. 

Jay

-- 
Jay Daley
IETF Executive Director

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Aug 2020 21:43:28 -0700

> I'm not sure I'm the best person to ask. John Levine has the most recent experience; I've been out of the loop since IETF 106 due to COVID and timezones. The kind of issues I recall that are not re…

But these are two examples of "one off" issues that are very much on the
policy side. What we are speaking about here is not the decision to get
a DOI for RFC, or the WG-like process to define a new XML format. My
impression is that the questions asked by the RPC tend to be related to
document authors with extraordinary requirements (Jay's example being a
caricature of that), or formatting requirements that expose an issue
with the tools or the XML v3 format such as "Can we in insert a line
break in the title". It is important that such questions be dispatched
quickly. Expertise helps, knowledge of the formats and the tools is
required. And yes, John could tell us more about that.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2020 17:01:29 +1200

> While I can see that’s the sort of thing we need an expert for I would imagine that the advice is to the community not the RPC as the RPC doesn’t have authority to make those kinds of changes. I ca…

"Continual" is not "continuous". So yes, these issues crop up episodically, not every day or every week. That's exactly why my current model is expressed as it is (and the analogy with a retained legal counsel is a good one).

> As I understand it, the style->XML->output chain is so tightly connected that most changes affect at least two if not three of those parts and that’s where the bulk of the work is, not the big tick…

I agree, and that's an IT management issue where I am *not* claiming that we need outside advisory expertise.
 
> It would indeed be helpful to get some current data about the nature of the “continual” work to see what skills are needed to support that. 

By its nature (i.e., unknown unknowns for we non-experts in publishing) it will be hard to quantify.

Rgds
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2020 08:23:56 +0200

> By its nature (i.e., unknown unknowns for we non-experts in publishing) it will be hard to quantify.

Yes, and the important part is what we are not doing because we don’t know we could be doing it.  E.g., DOIs were a useful step (even if they required climbing over some victims of previous battles) for integrating RFCs into the publishing streams where we want RFCs to be visible.  There is a lot more to do here, and the RSE would be in a position of developing the initiatives (or, also, reformulating initiatives coming from the community into a form that becomes actionable and effective).

This strategic part of the work is very different from the daily “how do I get a line break here and is that even something that should be possible” which is more technical in nature but nearly always has some long-term consequence (the “RPC guidance” work).  

The V3 project has some IT management components, but the RSE input that we need now to complete it is much about learning the actual consequences of decisions that were made and re-adjusting for the 2020s and beyond.  Some involvement in the troubles of the RPC is useful to make the right calls here.

Grüße, Carsten

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2020 16:46:36 -0400

In article <[email-masked]> you write:
>> Can I just tease this out a bit more.  From my limited exposure to the process, the majority of the work/fuss is about such things as "I want a bulleted
>list of contributors written RTL inside a table cell inside the acknowledgements section and right-aligned with a gap in this SVG artwork" (I’m exaggerating,
>but not by much).  It is not clear to me if this requires a publishing expert, a community process to manage an ever more sophisticated style guide and
>underlying schema/tools, or someone who is very good at saying ’no’.  Is this the sort of thing you had in mind when you talk about continual advice or is
>it something different?

At the moment I'm dealing with low level stuff like table formats and
where the page numbers go.

There are higher level issues someone should deal with someday like
whether it still makes sense for RFCs to be immutable point documents
or whether we should have updates and version numbers like everyone
else does.

There's also issues of authoring tools. In the world outside the IETF,
everyone uses MS Word and Google Docs to write their documents. While
those are not necessarily my favorite tools (Word sure isn't) the need
to use our exotic bespoke authoring tools is yet another barrier to new
IETF participants.

R's,
John

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 13:54:44 -0700

> to use our exotic bespoke authoring tools is yet another barrier to new

I'm no fan of our bespoke tools but this is not correct. WHATWG, W3C and
(afaict) TC39 use HTML-based formats.

-Ekr

---

From: "John R Levine" <[email-masked]>
Date: 28 Aug 2020 17:00:24 -0400

> (afaict) TC39 use HTML-based formats.

I wouldn't call any of them great examples of open participation either 
and for them it's eating their own dogfood, which xml2rfc is definitely 
not.

Look at IEEE or ANSI or ISO, you'll see a lot of MS Word.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 14:11:48 -0700

> Look at IEEE or ANSI or ISO, you'll see a lot of MS Word.

Well, this is a significantly different claim from the text I was
responding to: "In the world outside the IETF, everyone uses MS Word and
Google Docs to write their documents." I certainly agree that *some*
standards bodies use MS Word and Google docs.

It seems like the argument you're making is that (1) IEEE or ANSI or ISO
are better examples of open participation than WHATWG, W3C, TC39, and IETF
and (2) that has something to do with the document formats. I don't agree
with (1). To the contrary, taking PRs on Github seems significantly more
open that what I see in the SDOs you list. As for (2), I doubt that the
document format has much to do with one way or the other.

-Ekr

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 28 Aug 2020 23:25:50 +0200

> Look at IEEE or ANSI or ISO, you'll see a lot of MS Word.

I’m not sure that this is the discussion we want to have here right now, but let me point out that some of us are part of a world that has been weaning itself of that addiction, and we would never go back to that.

Those who do serious specification work at high velocity in these organizations often have their own bespoke tools for one specific project, e.g., see https://github.com/cplusplus/draft

Now we don’t have any document of this level of complexity (not even NFSv4 comes close), but having edited an RFC that was just one order of magnitude smaller, in MS-Word, I can tell you that I belong to the group that would never go back.

All this is on the authoring side, which has most definitely not been the focus of the V3 work, and getting a good pipeline that is inclusive to the people who prefer to work in MS-Word is certainly a useful follow-on project.

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 28 Aug 2020 19:03:26 -0400

>> to use our exotic bespoke authoring tools is yet another barrier to new

To perhaps clarify, I think that xml2rfc is an OK publication format 
because of all the semantic tagging, but it's a terrible authoring format. 
If it were up to me (and I had 20/20 hindsight) I would put more effort 
into thinking about the entire document creation process and better tools 
to let people use the editing tools they use for other stuff.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 28 Aug 2020 16:13:01 -0700

> to let people use the editing tools they use for other stuff.

Not totally sure I agree on the publication format, but 100% agree on the
authoring format.

-Ekr

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Aug 2020 17:34:20 -0700

> On Aug 28, 2020, at 4:03 PM, John R Levine <[email-masked]> wrote:
> 
> To perhaps clarify, I think that xml2rfc is an OK publication format because of all the semantic tagging, but it's a terrible authoring format. If it were up to me (and I had 20/20 hindsight) I would put more effort into thinking about the entire document creation process and better tools to let people use the editing tools they use for other stuff.

That’s why I support the Word format, FWIW.

I understand the back-end pubs process is harder when it goes to RFC, but that’s a 1x investment. Word (or word-like, e.g. OpenOffice) makes it impossible to generate “non-compiling XML” that can’t easily be untangled.

Joe

---

From: Michael StJohns <[email-masked]>
Date: Fri, 28 Aug 2020 21:43:18 -0400

Hi Joe -

Somewhere around 20+ years ago I watched in horror as one of the 
technical groups associated with the the US DOD adopted WordPerfect as 
its publication format. You can guess how that turned out.

We use XML with an easily interpreted schema as an archival publication 
format because the chances of someone being able to interpret it in 20 
years is near unity. The same cannot be said for Word, nor does "Word" 
specify the actual publication format given that Microsoft feels the 
need to change both its UI and its format at rest with each and every 
major version.

I hate authoring in XML - but I'm pretty sure that it will be renderable 
in some form in 30-50 years.

Mike

On 8/28/2020 8:34 PM, Joseph Touch wrote:
>
>
>> On Aug 28, 2020, at 4:03 PM, John R Levine <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> because of all the semantic tagging, but it's a terrible authoring 
>> format. If it were up to me (and I had 20/20 hindsight) I would put 
>> more effort into thinking about the entire document creation process 
>> and better tools to let people use the editing tools they use for 
>> other stuff.
>
> I understand the back-end pubs process is harder when it goes to RFC, 
> but that’s a 1x investment. Word (or word-like, e.g. OpenOffice) makes 
> it impossible to generate “non-compiling XML” that can’t easily be 
> untangled.
>
> Joe
>

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Aug 2020 20:15:26 -0700

Hi, Mike,

I’ve been using Word since 1988. Files from that time still opened in Word through 2016; it’s been simple to open those .doc in that version and save them in .docx - the ONE transition that’s been required in the intervening 32 years.

I can say that about NO other format except raw ASCII.

However, since you raised the point, I thought we were talking about the very useful difference between the authoring format and the archive format. I proposed that the RFC Editor should start supporting Word as an authoring format.

Publication of an RFC is equivalent to compilation. That step can take more time because it occurs once; we should be optmizing the other sides of the process - modern editing and persistent archiving, and not try to confuse the two.

And to be clear - the only way IETF’s XML will be renderable in 30 years is if someone from THIS community continues to support that. 

Joe

> On Aug 28, 2020, at 6:43 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi Joe - 
> 
> Somewhere around 20+ years ago I watched in horror as one of the technical groups associated with the the US DOD adopted WordPerfect as its publication format.   You can guess how that turned out.
> 
> We use XML with an easily interpreted schema as an archival publication format because the chances of someone being able to interpret it in 20 years is near unity.    The same cannot be said for Word, nor does "Word" specify the actual publication format given that Microsoft feels the need to change both its UI and its format at rest with each and every major version.
> 
> I hate authoring in XML - but I'm pretty sure that it will be renderable in some form in 30-50 years.
> 
> Mike
> 
> 
>>> On Aug 28, 2020, at 4:03 PM, John R Levine <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 28 Aug 2020 23:29:54 -0400

As far as I know, the RFC Editor does not themselves support any of the 
various authoring tools / toolchains.  Various people provide various 
tools.  The IETF has been, and I think should be, agnostic as to what 
tool authors use to prepare I-Ds.  (The one complication is that 
multi-author teams do need to agree on what tools they will use.)

The one time I had to work with a substantial RFC prepared in Word, it 
was a disaster.   And when the author who wanted to use Word moved on, 
the new pen-holder found it easier to go through the trouble of 
converting to XML than to try to get word to cooperate.  (Admittedly, 
Word has gotten a lot better since then.)

But to paraphrase the above, the RF Editor does not tell the IETF what 
tools to use to author I-Ds.

Yours,
Joel

On 8/28/2020 11:15 PM, Joseph Touch wrote:
> Hi, Mike,
> 
> I’ve been using Word since 1988. Files from that time still opened in 
> Word through 2016; it’s been simple to open those .doc in that version 
> and save them in .docx - the ONE transition that’s been required in the 
> intervening 32 years.
> 
> However, since you raised the point, I thought we were talking about the 
> very useful difference between the *_authoring_* format and the 
> *_archive_* format. I proposed that the RFC Editor should start 
> supporting Word as an authoring format.
> 
> Publication of an RFC is equivalent to compilation. That step can take 
> more time because it occurs once; we should be optmizing the other sides 
> of the process - modern editing and persistent archiving, and not try to 
> confuse the two.
> 
> And to be clear - the only way IETF’s XML will be renderable in 30 years 
> is if someone from THIS community continues to support that.
> 
> Joe
> 
> 
>> On Aug 28, 2020, at 6:43 PM, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Joe -
>>
>> We use XML with an easily interpreted schema as an archival 
>> publication format because the chances of someone being able to 
>> interpret it in 20 years is near unity. The same cannot be said for 
>> Word, nor does "Word" specify the actual publication format given that 
>> Microsoft feels the need to change both its UI and its format at rest 
>> with each and every major version.
>>
>>> but that’s a 1x investment. Word (or word-like, e.g. OpenOffice) 
>>> makes it impossible to generate “non-compiling XML” that can’t easily 
>>> be untangled.
>>>
>>> Joe
>>>
>>
>> -- 
>> [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Aug 2020 23:35:57 -0400

FWIW, one flow that I’ve seen work pretty well is to do the editing in Google Docs, which has similar features to Word, but is portable and supports simultaneous editing. The usual mode is to use the RFC markdown format rather than XML, because it’s easier to edit. This can be extracted as a text file and run through markdown whenever a new version needs to be generated, so it’s pretty low stress compared to trying to extract a Word document’s formatting.

I think Word works pretty well if everybody is using it and nobody tries to do anything fancy, but it wouldn’t work well in an IETF context because probably fewer than half of participants run Windows, and compatibility issues between Word on Windows and Word on Mac are kind of par for the course. OpenOffice does a surprisingly good job, but is not pleasant to use.  But the multiple editors feature of Google Docs makes the choice really obvious.

It would be nice if someone wrote a tool that allowed us to edit the XML directly with the same suggesting/commenting/editing capability that Word and Google Docs provide, but I don’t think that’s within the IETF’s capabilities.

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Aug 2020 20:53:26 -0700

The RFC Editor is indirectly involved in constraining author formats by limiting them to IETF XML or TXT 

Currently, we can submit in raw IETF XML source or ASCII text formatted per RFC 7994. Those choices constrain authoring tools to systems that can emulate a 1970s line printer or edit 1970’s style source code.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Aug 2020 00:00:56 -0400

> Currently, we can submit in raw IETF XML source or ASCII text formatted per RFC 7994. Those choices constrain authoring tools to systems that can emulate a 1970s line printer or edit 1970’s style s…

It sounds like you’re arguing that RFCs should be in Word .doc format.

If you are not, then what you’ve said doesn’t make sense. Any tool that generates text in a form that can be mechanically transformed into the XML source will do. There are actually Word document parsers that can be made to do this. Probably could also be done for Google Doc, which has the better feature set.

However, the work involved in making this happen would be more than the work involved in just doing markdown. So we just do markdown. It’s not work the effort to fix it, or we would have done.

---

From: Joseph Touch <[email-masked]>
Date: Fri, 28 Aug 2020 21:38:25 -0700

> On Aug 28, 2020, at 9:00 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Aug 28, 2020, at 11:53 PM, Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:

Authorable in that format; not published in it. 

> However, the work involved in making this happen would be more than the work involved in just doing markdown.

This is like arguing that a compiler doesn’t save work vs. writing in assembler.

> So we just do markdown. It’s not work the effort to fix it, or we would have done.

If everyone agrees, sure. Point raised, point ignored. Point taken.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Sat, 29 Aug 2020 10:08:44 +0200

Hi!

Thanks, John, for reminding us of what you are doing and what may well need doing later.  I hate going into the weeds, and this conversation is very much there, but I want to highlight one aspect of all of this, before the chairs pull out the lawn mowers ;-)

I am going to use you, John, and you EKR to try to bring into focus the role of the experts and the role of the community.

> On 29 Aug 2020, at 01:13, Eric Rescorla <[email-masked]> wrote:
> 
> Not totally sure I agree on the publication format, but 100% agree on the authoring format.

I think you’re right to say that you are not sure you agree on a publication format.  Do you even know what questions to ask to determine the answer?  I sure don’t.

Let’s envision a scenario where the community decides, “we want tooling that can take as input common forms of author editing tools such as Word, Google Docs, emacs, vi, and whatever comes next.” (Mike, we’ll leave Word Perfect on the cutting room floor for a moment ;-).  We further say, “We want the tooling to produce an output suitable for publication.”

This would involve someone coming up with a considered architecture, someone or someones developing a plan, someone executing that plan, someone overseeing the execution, someone answering questions, managing variances that will surely arise, and addressing evolving circumstances.

If a variance arises, how agile must our process be to address that?  Would a WG have to answer questions about all variances?  Would rough consensus have to be achieved? Would work stop in the meantime?  If we say that the WG must approve only those variances that seem to change the architecture, who decides that question?

Where does the community want to have a voice in all of this, and where do we want to delegate?

How would this work with each of the approaches we find in the current drafts today?

Eliot

---

From: Joe Touch <[email-masked]>
Date: Sat, 29 Aug 2020 09:02:25 -0700

> On Aug 29, 2020, at 1:09 AM, Eliot Lear <lear=[email-masked]> wrote:
> 

They’re called publishers.  We are very bad at this, for the reasons you cite. Professional publishing houses do this for a living.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 29 Aug 2020 12:09:36 -0400

> I think you’re right to say that you are not sure you agree on a publication format.  Do you even know what questions to ask to determine the answer?  I sure don’t.

The publication format belongs to the IAB, so we would ask them whether 
they are prepared to throw away the five years of work that produced RFCs
7990, 7991, 7992, 7993, 7994, 7995, 7996, 7997, and 7998 and start over,
before the transition to the current format is even complete.  Since I
think we can all guess what the answer to that question would be, let's not.

A more productive place to look is at the overall process that produces RFCs,
from initial I-D's through adoption and revision and eventually publication.
It is extremely strange that although we purport to be dedicated to open
standards, our publication process mostly uses custom stuff used by nobody
else in the world, e.g., xml2rfc, Carsten's markdown translators.

Each time someone proposes we use tools that other people use, there's 
pushback for reasons some of what make sense but others that seem to me to 
be utterly hypothetical. (I do not think that Microsoft is likely to 
cripple github; they obviously bought it defensively to keep it away from 
Facebook.)

I'd go up half a level and see if the community can figure out what its
big picture goals are.  Do we understand what community RFCs actually
serve, both on the producing side and the consuming side.  How is that
process serving or not serving those communities.  In some ways we're
clearly in good shape, notably being the first SDO to offer free public
access.  But in others, not so much.

Regards,

---

From: Jay Daley <[email-masked]>
Date: Sun, 30 Aug 2020 07:54:03 +1200

Eliot

> On 29/08/2020, at 8:08 PM, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi!
> 

When you’re considering this, don’t forget that we have the recently minted Tools Architecture and Strategy Team that is tasked with looking at some of these things. 

-- 
Jay Daley
IETF Executive Director

---

From: "John Levine" <[email-masked]>
Date: 29 Aug 2020 16:36:14 -0400

In article <[email-masked]> you write:
>I’ve been using Word since 1988. Files from that time still opened in Word through 2016; it’s been simple to open those .doc in that version and save them in .docx
>- the ONE transition that’s been required in the intervening 32 years.
>

We troff users would take issue with that. I'm pretty sure I have
troff source from the 1970s that I can still run through groff.

More to the point, though, the DOC files from the 1980s were in a
binary tokenized format while modern DOCX are zip archives of several
XML files.  They only thing they have in common is that Microsoft will
sell you a program called Word that can read them.  While that is swell
for Microsoft's customers, it's not a great argument about stability.

Again, if people want to use it for authoring I think investing in
better tools to create xml2rfc directly or indirectly from Word would
be fine, but authoring and publishing are different.

>And to be clear - the only way IETF’s XML will be renderable in 30
years is if someone from THIS community continues to support that. 

Not at all -- when we're looking at archival formats, robustness is part
of the discussion.  Our format is based on XML, which is unlikely to be
forgotten, and it's stored as UTF-8 which is equally unlikely to be
undisplayable.  So even if all of our tools disappear, you can just look
at the XML and see the text, and if you wanted, reverse engineering the
XML grammar to help render it better would not be hard.

While I don't think DOCX will disappear either, it doesn't have the semantic
tagging of our XML and I can tell you that it is not easy to find the text
when you unzip the archive and look at the contents.

The reason I'm going through all this is to point out that there is a
lot of expertise in publishing that more IETFers don't have, and we should
remember that there are often times when asking actual experts (not me) for
advice is a good idea.

R's,
John

---

From: Joseph Touch <[email-masked]>
Date: Sun, 30 Aug 2020 08:21:11 -0700

The two points you also agree below (in bold) are the only ones I was actually trying to raise.

Joe

> On Aug 29, 2020, at 1:36 PM, John Levine <[email-masked]> wrote:
> ...
> ...

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2020 10:41:35 -0400

--On Saturday, August 29, 2020 16:36 -0400 John Levine
<[email-masked]> wrote:

> In article
> <[email-masked]> you
> write:
>> I've been using Word since 1988. Files from that time still
>> opened in Word through 2016; it's been simple to open those
>> .doc in that version and save them in .docx - the ONE
>> transition that's been required in the intervening 32 years.
>> 
> We troff users would take issue with that. I'm pretty sure I
> have troff source from the 1970s that I can still run through
> groff.

That is ok because, if one were prescient to choose the right
markup to use and not be very clever, contemporary groff will
process CTSS runoff files from the first half of the 1950s.  See
below for the point other than historical curiosity. 

> More to the point, though, the DOC files from the 1980s were
> in a binary tokenized format while modern DOCX are zip
> archives of several XML files.  They only thing they have in
> common is that Microsoft will sell you a program called Word
> that can read them.  While that is swell for Microsoft's
> customers, it's not a great argument about stability.

Indeed.  
 
> Again, if people want to use it for authoring I think
> investing in better tools to create xml2rfc directly or
> indirectly from Word would be fine, but authoring and
> publishing are different.
 
>> And to be clear - the only way IETF's XML will be 
>> renderable in 30 years is if someone from THIS community
>> continues to support that. 

First of all, when professionals in the document preservation
field talk about "archival" they are talking about many human
lifetimes: centuries rather than a few decades.  For media,
stone and clay tablets protected against breakage, the right
sort of paper and careful preservation conditions are good.
Most other things (including most modern CDs, DVDs, etc., and
anything magnetic) require some plan about periodic duplication,
making sure that the duplication process does not lose
information and that it comes with its own guarantees about
long-term (again many centuries) repetition.  I think Heather's
arrangements with repository libraries that already have several
centuries of history, practice, and tradition will serve us very
well but being sure about electronic/digital  media would
require a time machine and ability to look ahead into the next
millennium (at least.

Depending on the IETF community to continue to support a format
for 30, much less a few hundred, years, presumes that the IETF
will be around, perhaps even more or less in its current form,
for that period.  The only think that would prevent me from
taking bets is that I'm fairly sure I won't be around to collect.

> Not at all -- when we're looking at archival formats,
> robustness is part of the discussion.  Our format is based on
> XML, which is unlikely to be forgotten, and it's stored as
> UTF-8 which is equally unlikely to be undisplayable.  So even
> if all of our tools disappear, you can just look at the XML
> and see the text, and if you wanted, reverse engineering the

And this is where I think we have some disagreement.  For the
RFC Series, if page layout is considered significant (with the
RFC Series it has been for most of the last 40 years but
arguably was not for the first decade) being able to read the
text and mentally discard the markup isn't good enough.  If one
doesn't care about formatting generally, things like tables can
be a challenge to read and interpret but that now becomes much
more challenging with non-ASCII drawings and figures because the
issue is not just XML but, e.g., SVG.   With the additional
markup in v3, some of which is close to formatting, rather than
generic, markup, decoding -- figuring out which markup and
elements can be ignored and which ones have to be interpreted
and interpreted accurately is much more challenging than "not
very hard" would imply.  

As to the longevity or XML (or SVG), what was that quote
attributed to Zhou Enlai about the French Revolution?   :-(
 
> While I don't think DOCX will disappear either, it doesn't
> have the semantic tagging of our XML and I can tell you that
> it is not easy to find the text when you unzip the archive and
> look at the contents.

Yes.  And, if a slightly earlier format makes a good comparison
to think about, I can supply some source documents in
first-generation Word Perfect -- a format which, at the time,
people felt would be around for a very long time because it was
being used for so many documents -- for people to examine.

> 
> The reason I'm going through all this is to point out that
> there is a lot of expertise in publishing that more IETFers
> don't have, and we should remember that there are often times
> when asking actual experts (not me) for advice is a good idea.

Exactly.

    john