Re: [Rswg] Making progress on RFC 7991-bis

[Eric Rescorla <[e-mail]>]

On Fri, Aug 12, 2022 at 3:00 PM Brian E Carpenter <
[e-mail]> wrote:

> Jay,
>
> On 12-Aug-22 23:42, Jay Daley wrote:
> > Brian
> >
> >> On 11 Aug 2022, at 22:36, Brian E Carpenter <
> [e-mail]> wrote:
> >>
> >>> deprecation is only forward guidance that this feature will be removed
> in a future version.
> >>
> >> Hate to repeat myself, but this implies a definition of "deprecate"
> that makes archived XML files invalid. For now we clearly do not have
> consensus that this is OK. (My comment yesterday on
> draft-hoffman-rfc7990-updates-01 effectively suggests a way to resolve
> this.)
> >
> > I think we have a very different understanding of XML and XML grammars.
> >
> > Once an XML document is published, the formal grammar is irrelevant.
>
> Ah, but it's relevant if somebody decides to repeat the process of
> rendering the original XML file into one of the presentation formats, or
> even into a brand new presentation format that hasn't been invented yet.
> Current rendering tools would presumably be incapable of rendering a
> feature that was deprecated many years ago. That's all I mean by "invalid".
>
> We could decide that we don't care about this, but if so that decision
> needs to be clearly documented (e.g. in RFC7990bis).
>
> Apart from that, I agree with all you say below.
>

[As an individual]

It's actually not even clear to me that it's irrelevant once it's
published. Trying to avoid words like archival and canonical, we need some
agreement on what the definitive way to interpret a document is.

For instance, do we:
1. Read the XML and mentally interpret the meaning from the grammar
definition.
2. Render the text with the currently valid tools and use one of the
versions
3. Render the text with the tool version current when the XML was generated
4. Use one of the contemporary rendered versions

And of course for (2)-(4), which of the versions do we look at?

It seems to me that all of these require understanding the grammar [0]

-Ekr

[0] You might think that (1) didn't, but consider the totally hypothetical
case of a document which says:

The value of constant X is 2<sup>2</sup>.

I think we would all agree that the meaning of <sup> is relevant to the
interpretation of the document.



>
>     Brian
>
> > This is because the sole purpose of that grammar is to define what XML
> is allowed in the document but once the document is published that
> discussion is over. What’s in it is what’s in it.  When people come to
> read/process/consume an XML RFC/i-D they do not need the grammar to do that
> as it does not contain any information that is not in the RFC/I-D.  So for
> me there is no concept of "invalid archived XML files".
> >
> > What matter when the document is published is ensuring that people can
> correctly read/process/consume a published document and that means having a
> well documented and consistent meaning for each XML element/attribute
> used.  If it’s not clear, this is because, at this point it is the
> published XML that is being consumed not the grammar.  A major problem to
> avoid here is if we were to have an inconsistent meaning, such as one set
> of RFCs where <foo> means "a suggested name" and another set where <foo>
> means "a prohibited name".  This is a problem irrespective of whether we
> have one and only one current grammar that RFCs are retrospectively
> adjusted to fit with, or whether we have 100 versioned grammars.
> >
> > The one use case where "what if we introduce a new grammar that old
> documents would not validate against" actually matters is when published
> documents are used as the starting point for new documents.  I personally
> think the best approach here is to provide a conversion tool that is used
> by an individual at the time they start the new document and with them
> making manual decisions to adjust the conversion.  After all, that’s what
> we do for v2 to v3.  The alternative of pre-converting every XML I-D,
> unprepped RFC and prepped RFC seems highly unlikely to be more efficient.
> >
> > Jay
> >
> >>
> >> Otherwise I think both of Jay's messages are very much to the point.
> >>
> >> Regards
> >>    Brian Carpenter
> >>
> >> On 12-Aug-22 02:57, Jay Daley wrote:
> >>>> On 2 Aug 2022, at 18:07, Eric Rescorla <[e-mail]> wrote:
> >>>>
> >>>> 1. Do we need to publish the current de facto format as an
> >>>>     RFC or should it be in some other form such as an I-D
> >>>>     or a Web page?
> >>> I believe it should be an RFC because that forces a specific process
> on us whereby there is a lot of discussion, each new version incorporates a
> big set of changes and new versions are infrequent and well distributed.
> By contrast, a web page or I-D would quickly become a much faster changing
> process with each new version having a small number of changes.  I see the
> former process as better for the following reasons:
> >>> 1.  As has been amply demonstrated, allowing a relatively quick, much
> less visible and non-consensus change process has got us into a mess.
> >>> 2.  Almost every change that might go into the grammar has a
> significant level of complexity and a full WG process is the best way to
> tease out that complexity and ensure that any changes are good changes.
> >>> 3.  We have never had an example of an urgent change needed to the
> grammar such that the RFC development process would be too slow.
> >>> 4.  We have many people in the community who still use v2 and even
> those who use v3 are using different versions depending on how up to date
> their xml2rfc is, and what files they copied into working directories
> when.  A slow running RFC process is the best fit to the way the community
> works whereas a fast changing process will increase this lack of cohesion.
> >>> 5.  If we want to move from the situation where we have only two tools
> (xml2rfc and Julian’s XSLT) that directly support the grammar, to an
> ecosystem of tools that do so, then an RFC is the best support of that from
> an implementer perspective.
> >>> 6.  One element of the mess has been identifying where the
> authoritative version of the grammar can be found.  Until recently that was
> the rnc source file as found in the subversion repository of the xml2rfc
> tool.  Now it is this file in GitHub
> https://raw.githubusercontent.com/ietf-tools/rfcxml-templates-and-schemas/main/rfc7991bis.rnc
> but other than us simply declaring that, there’s no way to always point to
> that.   If we have an RFC then that becomes the authoritative source.
> >>>>     2. Should we just publish the de facto format as-is
> >>>>     or should we make limited changes prior to the completion of
> >>>>     a more complete format document? If the latter, what process
> >>>>     should we use to vet those changes?
> >>> Sorry, this is a complex answer:
> >>> A.  Yes we must document the de facto grammar as is.  Please note that
> there are three parts to this:
> >>>    i.  The changes documented in
> https://www.ietf.org/archive/id/draft-levkowetz-xml2rfc-v3-implementation-notes-13.html
> >>>    ii.  The elements defined in the grammar that are not documented in
> any RFC such as <toc>
> >>>    iii.  There are a number of xml2rfc specific processing
> instructions (those of the form <?rfc … >) and these, while not strictly
> part of the grammar, were the only way to achieve things in v2 that can now
> be done in the v3 grammar and so were effectively obsoleted by RFC 7991
> thought that was never explicitly stated. It would be very useful to have a
> simple statement that all xml2rfc specific PIs are now obsoleted because
> people are still confused by this.
> >>> B.  This new RFC should describe version "3.1" of the grammar,
> reflecting its backward compatibility rather than be also be numbered v3 or
> jump to v4.
> >>> C.  If the chairs think we can reasonably quickly get agreement on
> deprecating any features (such as the complex postal stuff) then that
> deprecation should follow the normal use of deprecation - the grammar
> feature remains and can be used as before and deprecation is only forward
> guidance that this feature will be removed in a future version.
> >>> D.  I would like to see this document formally rename "The xml2rfc
> vocabulary" to "RFCXML" reflecting the de facto renaming in the
> authoritative documentation and the discussion around that on the
> tools-discuss list.  I’ll post a separate message reminding people why this
> has happened and re-opening the discussion to see how this group feels
> about it.
> >>> Jay
> >>>>
> >>>> - Pete and Eric (as chairs)
> >>>>
> >> --
> >> rswg mailing list
> >> [e-mail]
> >> https://mailman.rfc-editor.org/mailman/listinfo/rswg
> >
>