[Rswg] Snapshots versus normative specificatoins

[John C Klensin <[e-mail]>]

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

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