--On Thursday, 29 November, 2007 10:16 +0100 Julian Reschke
<julian.reschke@xxxxxx> wrote:
>> Yes, you're taking this entire line of commentary completely
>> out of context.
>> This was all in response to Eliot's suggestion that XML
>> versions of the document should be required at the time of
>> WGLC. John K responded to that advising caution for various
>> reasons and I chimed in with the additional reason
>> that this will force people to generate standalone
>> intermediary versions for submission.
>
> I'm aware of what started the discussion.
>
> However, when I use the submission tool today, I may not even
> know whether a particular version I submit will be a WGLC
> version. So I think whatever is the right answer for WGLC or
> LC is also the right answer for any ID version.
In most of the WGs I've worked with in the last few years, the
editor (and usually everyone else) know because there is an
explicit discussion about which version is going to be used for
for WGLC before it is posted. But assume my experience is
abnormal.
First, alternate cures for that problem include:
(i) Permitting posting the XML when it becomes clear
that a particular version is going to be the WGLC
version, even after the text version has already been
posted. (Whoops, not permitted by current automated
tools and raises all of the same issues about proving
synchronization that started this discussion.)
(ii) Simply posting a new I-D, in both text and (for the
first time) XML versions, once the WG concludes that it
wants to initiate a WGLC. With I-D posting times now
measured in minutes, rather than days, this is quite
plausible, even if the only the date and version number
change. (Whoops, we still have the synchronization
problem -- if an editor wants to smuggle something in,
nothing in the current tools checks that a posted text
version is identical to XML, HTML, or PDF versions posted with
it.)
But WGLC is still the wrong time to _require_ posting XML, at
least as long as we treat the text version as authoritative for
review and approval purposes. The right time to post the XML is
whenever the author or editor believes is the right time to post
the XML, with the understanding that posting it earlier rather
than later may be convenient for some WG members or reviewers
but that there are many reasons to delay its posting, many of
which Ned and I have
summarized.
If anyone, including the RFC Editor, is going to use an XML
version for anything in, or at the end of, the approval process,
they clearly have the responsibility to verify that it is a
reasonable match for the text and, if there are differences,
that those differences are acceptable. Note that this same
issue arises when an editor submits a revised text form to the
RFC Editor or to an AD for editing/ review convenience -- it
ultimately has little to do with whether XML is involved and
both happen.
If one is looking for a guarantee that an XML version matches
the published text without verifying it oneself, that guarantee
comes only when the RFC Editor posts the XML. Even that
reflects only textual identity because it is perfectly plausible
for the RFC Editor to process the XML into nroff (or the
formatting language of their choice) and then use the nroff to
fine-tune details of page layout. XML generally, and xml2rfc in
particular, do not specify page format to nearly the degree that
may be appropriate for a published RFC. To "fix" them to do so
would remove much of the attraction of generic markup.
So, at least in retrospect, the whole theme of this thread seems
to me to have been misguided. What we have is:
(1) When XML is submitted to the RFC Editor, it would be
helpful to the RFC Editor if the editor supplied a note
indicating how, if at all, it differed from the posted
version. With or without such warnings, the RFC Editor
needs to verify things submitted to them in XML form to
verify that they adequately match the text -- and that
is true both of initial submission versions and anything
comes back in from AUTH48 correspondence.
Fortunately, being sensible and careful people, the RFC
Editor is doing that already.
(2) If the RFC Editor accepts changes from an author (or
AD) that they should not be accepting, it is a problem
that has little to do with whether those changes are
submitted in the XML, in text, in the old "change this
to that" form, or over the telephone. Opinions differ
in the community as to the extent of changes the RFC
Editor should be able to make without asking for
permission and the changes an AD should be able to
approve without asking for a new Last Call, but those
are not XML submission issues.
(3) Authors, editors, and WG Chairs should figure out
the appropriate maturity level of drafts for getting XML
posted, with considerations that Ned and I have
mentioned figuring into that consideration along with WG
and Editor convenience in pasting in text, as well as
the fact that we still do not require that documents be
produced with XML or that XML _ever_ be produced as part
of the editing process.
(4) If the RFC Editor, or WG Chairs or ADs, want
summaries of how the editor believes that the XML form
of an I-D differs from the text form, it might not be a
bad idea for them to specify the form in which they want
that information (e.g., out of band in email versus an
XML comment in a particular place versus a special sort
of comment element). I hope we can avoid getting
sufficiently bureaucratic that we have to make such a
thing a requirement.
None of the above requires new procedures, just the copious
application of good sense on a case-by-case basis. If we lack
the good sense, and the good will needed to apply it, we have
far bigger problems than whether XML source matches the
authoritative text form or not.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf