Re: [Tools-discuss] Single source throughout. (Was creating bis docs automatically)

[Eric Rescorla <[e-mail]>]

[Since we are now in RSWG, noting that I am speaking as an individual.]

On Mon, Mar 6, 2023 at 6:56 AM Jay Daley <[e-mail]> wrote:

> Adding in RSWG.
>
> On 4 Mar 2023, at 14:54, Eric Rescorla <[e-mail]> wrote:
>
> In that vein, I think that we should recognize that traditional publishing
> is an activity organized
> for the convenience of the publishers, not for the authors. However, in
> this case, what we have
> is more akin to self-publishing, with the RPC being more like a contract
> publisher, and so matters
> ought to be arranged for the convenience of the customer, which is to say
> the IETF, IAB,
> ISE, etc. That is, of course, not the end of the analysis, but suggests
> that the question of how
> things usually happen is not the right test.
>
>
> While there are many who agree with you, a not insignificant proportion of
> the community consider the RFC Series as somewhat independent and that the
> RPC is there to serve the series not the current "customers".
>

Without getting into this question, these process matters seem to be
precisely those
on which the streams have the strongest ground to have opinions.


To put my point another way - the current working practices assume an
> implicit model for the editorial/publishing function, which I suspect has a
> strong foundation in the history of the series.  Some proposed changes to
> the working practices will inevitably lead to questions about what that
> means for the model.  For example, if we have a single canonical source
> controlled by the authors does that mean that they now have to give
> permission for every change the RPC wants to make and do we now have to see
> the stream managers adjudicating every disagreement?
>

This is the way it is now in AUTH48, because the authors need to sign off
on the
document.


>
> Some might think that a document can basically re-enter the authoring
>> phase when someone chooses to write a -bis but again it’s our model that
>> sets the structure here. Our model does not have versions of RFCs and so
>> writing a -bis is starting a new document and a new source history, not
>> continuing the previous one.
>>
>
> Much could be said about books, and yet, as noted above, in many book
> publishing workflows,
> the author is left with a copy of the corrected manuscript.
>
>
> I don’t think there is any suggestion that they can’t get that. The
> discussion as I understood it was about a single draft-to-publication
> source history. If all the authors wanted was the equivalent of a corrected
> manuscript then they could clone the RPC repository and go from there.
>

Putting "clone" aside, the question is whether the output of the RPC
process is suitable
for trivially reinserting into the draft preparation process. And the point
is that it's not
for those who work in non-XML formats, as they must backport the changes.

-Ekr


> Jay
>
>
> -Ekr
>
>
>> Sure, I understand that there is a modern alternative model for
>> developing technical standards of living documents, no separate publication
>> role/phase, and a single start-to-finish source history, but what we do is
>> quite different.
>>
>> Jay
>>
>> --
>> Jay Daley
>> IETF Executive Director
>> >
>> > Cheers,
>> > Martin
>> >
>> > [1]  A particularly challenging one, as it turns out.  The breadth of
>> changes the RPC makes does tend to be quite hard to track.  But it
>> generally only takes a few hours, even on a very long document.
>> >
>> >> On Sat, Mar 4, 2023, at 07:36, Jean Mahoney wrote:
>> >> Just thinking out loud -- I think it would helpful for author-tools to
>>
>> >> provide an option of starting a bis doc.
>> >>
>> >> On author-tools, an author could enter the number of the RFC they want
>>
>> >> to create a bis draft for, provide a draftname for it, and select a
>> file
>> >> format (XML or markdown). author-tools (or whatever is behind the
>> >> curtain) would then fetch the RFC file from rfc-editor.org, do the
>> >> necessary updates (e.g., removing the RFC number), and make a file
>> >> available for download.
>> >>
>> >> I've created an enhancement request:
>> >> https://github.com/ietf-tools/ietf-at-ui/issues/152
>> >>
>> >> Thanks!
>> >> Jean
>> >>
>> >>
>> >>> On 3/3/23 2:07 PM, Jean Mahoney wrote:
>> >>> Hi Paul,
>> >>>
>> >>> On 3/3/23 12:58 PM, Paul Hoffman wrote:
>> >>>> On 3 Mar 2023, at 10:54, Jean Mahoney wrote:
>> >>>>
>> >>>>> Converting the file to v3 will remove the warning about
>> >>>>> rfc2629-xhtml.ent the next time you run xml2rfc. You don't have to
>> >>>>> make any changes to the file before uploading it to
>> >>>>> author-tools.ietf.org to convert it.
>> >>>> OK, this is useful. I propose that when authors ask the RPC for the
>> >>>> last XML because they're making a -bis, that this be suggested to
>> them.
>> >>> [JM] authors.ietf.org could also provide more info, then the RPC
>> could
>> >>> provide a pointer to it. I created an issue:
>> >>> https://github.com/ietf/authors.ietf.org/issues/56
>> >>>
>> >>> Thanks!
>> >>> Jean
>> >>>
>> >>>>
>> >>>> I can handle this easily from here.
>> >>>>
>> >>>> --Paul Hoffman
>> >>>>
>> >>>
>> >>> ___________________________________________________________
>> >>> Tools-discuss mailing list - [e-mail] -
>> >>> https://www.ietf.org/mailman/listinfo/tools-discuss
>> >>>
>> >>
>> >> ___________________________________________________________
>> >> Tools-discuss mailing list - [e-mail] -
>> >> https://www.ietf.org/mailman/listinfo/tools-discuss
>> >
>> > ___________________________________________________________
>> > Tools-discuss mailing list - [e-mail] -
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>>
>> ___________________________________________________________
>> Tools-discuss mailing list - [e-mail] -
>> https://www.ietf.org/mailman/listinfo/tools-discuss
>
>
> --
> Jay Daley
> IETF Executive Director
> [e-mail]
>
>