Re: [Rswg] Snapshots versus normative specificatoins

[Brian E Carpenter <[e-mail]>]

The time zone means that I'm sitting out this week, but some
comments below:

On 26-Jul-22 08:56, John C Klensin wrote:
> Hi
> 
>>From what I could tell from this distance, people were saying
> things but not quite communicating with each other.  In case it
> might help, let me see if I can reformulate the problem.   As a
> user of the xm2lrfc v3 vocabulary and one of the tools that
> compiles documents supposedly written in it, I have three places
> to look for a definition of that vocabulary:
> 
> 	RFC 7991
>    draft-iab-rfc7991bis-04
> and
>    https://xml2rfc.tools.ietf.org/xml2rfc-doc.html

We certainly need to decide which of the second two "counts",
but as my issues list asserts:

"(8) Format evolution.

The policy question is to decide who is in charge of format
evolution. Who debates and who decides? The technical
details (e.g. XML2RFC fixes, SVG usability) don't belong
in the RSWG, so where do they belong?"

In my mind the questions for the RSWG are: Where is the authority
on this? Where is the debating chamber for the technical details?
Who calls consensus?

John's remarks and questions below are all on the mark, IMHO,
but my questions remain open.

    Brian

> 
> AFAICT, no two of them define exactly the same vocabulary.   It
> is a trivial matter by comparison, but we can't even agree on
> what that is called -- the three documents refer to "xml2rfc v3
> vocabulary" but there are other IETF documents (or at least web
> pages) that believe it is called RFCXML.
> 
> The charitable term for this from a user standpoint is "big
> mess".  It also (as I think Mark was suggesting) a very sad
> state of affairs for IETF, an organization that is supposed to
> be promoting interoperability.
> 
> So, a suggestion
> 
> :
> 
> (1) If it is possible to pick the one of those that actually
> reflects the current state of the tools team supported
> implementation, whip it into shape for publication, make sure it
> says clearly that it is an informational document in the most
> traditional sense -- to inform the community about the current
> status of a particular implementation -- that it does not update
> or replace 7991 in any way, _and_ that it is not a guide or
> target for other implementations.  Given the amount of confusion
> we have had already, all of that should be spelled out in the
> document, not left implicit. If the IAB can approve publication
> of that document this week (while the RSWG and RSAB are trying
> to nail down their publication approval procedures), and the
> IAB, RSAH. and RSWG Chairs can plead with the RPC to prioritize
> it, that would be, IMO, a Good Thing.
> 
> I note that there are a few things in some of the existing
> documents about which I, again speaking as a user of the system,
> am completely confused.  If this were being published as a
> consensus document, I'd be whining about fixing them, just as I
> and others would be complaining about what it said.  However,
> the IAB gets to publish non-consens8s things for community
> information (not unlike the ISE) and that, IMO, is exactly what
> is needed now.
> 
> (2) _Then_ we use that snapshot document as a sort of diff from
> 7991 to start seeding the ticket/issues list with "is this what
> we really want?" questions and at least some of the more
> fundamental ones that I gather Julian, Mark, myself, and others
> want to ask.  RSWG then figures out how to make progress toward
> a normative document (or normatively documenting an evolutionary
> process) to which we would like other implementations to conform
> and users to believe is actually going to be stable for a while.
> 
> That leads to a few high-level questions that I hope the RSWG
> can address early on (there are probably overlaps between these
> and Brian Carpenter's list):
> 
> (i) I think we all owe thanks to the Tools Team (and Robert in
> particular) and John Levine for making improvements, even with
> the vocabulary, when they hit barriers and the alternative was
> waiting until this group was created and able to sort itself
> out.  I don't like some of the choices they made and, judging
> from the meeting, there are choices that Mark, Julian, and
> others don't like either, but we could easily be in even worse
> shape.   Is it the RSWG's position that, once that snapshot is
> published, changes that affect the vocabulary stop until the
> RSWG can make decisions (at whatever granularity the group
> decides upon)?
> 
> (ii) What the community agreed to when RFC 7990 was published
> was that the XML form would be the archival format for RFCs.
> That means it is absolutely dead stable regardless of whether
> the output formats change:  no assuming that we can somehow
> collect all of the copies (of the XML for) published RFCs that
> are scattered all over the world and adjust them to
> incompatiblechanges which we make to the vocabulary as we move
> along and learn from experience.  I heard several things on the
> call and read them on the chat that implied going back and
> retrofitting the XML of already-published documents.  That is,
> IMO, A Big Deal and a big policy one at that.   It probably
> implies a revision to RFC 7990, which is nearly as fundamental a
> policy document as, e.g., RFC 8728.   So either we need to make
> sure that the definition of the vocabulary _and_ the tools are
> strictly backward compatible, or we have some rather large
> decisions to make.  And, IMO, no one should start retrofitting
> old documents until those policies are clear.
> 
> We may very well discover that we need to hold our noses and do
> uncomfortable things, but I'd hope that would be a carefully
> thought-out decision that goes through the process with due
> consideration for not having to do it again (ever), not as,
> e.g., an adjustment to tooling.
> 
> (iii) When Marshall and Carl started us down this path, the
> assumption was that the vocabulary would be simple enough to be
> used as a tool for authors who were far more interested in the
> substance of their writing than on formatting, layout, or
> metadata issues.  They also intended that it would conform to
> general principles of generic markup (which, to some extent, is
> saying the same thing differently).  While v2 arguably moved
> somewhat away from that model, it is now far away in the rear
> view mirror.  The observation that many members of the community
> have created or adapted tools that allow them in write in much
> simpler form, with those tools then translating into xml2rfc,
> suggests that all or part of that original goal has been
> abandoned.  As a policy matter, if our plan is to treat the
> xml2rfc language (RFCXML?) as something analogous to a machine
> language or assembly language to which other tools translate;  a
> language in which some people might write if they are perverse
> enough to want to but that is not expected to be the norm, that
> has some significant implications.   If we decide instead that
> actually writing the XML is an option was want to preserve and
> encourage, that has different implications.  Either way, it is a
> rather large policy decision, one that may affect both document
> authors and design decisions about the vocabulary within the
> RSWG's scope but that may also affect EMODIR efforts, the
> ability to attract, integrate, and retain newcomers, etc.  (The
> recent questions on the tools list about how many people are
> doing what hint at this same issue, but I believe it should be
> discussed as a policy issue not a "what who is doing" one.)
> 
> best,
>     john
> 
> 
> best,
>     john
> 
>