On 2017-09-22 18:54, Heather Flanagan (RFC Series Editor) wrote:
On 9/22/17 5:51 AM, Julian Reschke wrote:
On 2017-09-14 23:07, Heather Flanagan (RFC Series Editor) wrote:
...
The RPC and the Tools Team has identified several areas that need to be
modified to support these characters. Some of those areas will
ultimately be handled with the new format tools; others have been
modified as part of the more general work to prepare for the new RFC
format. For the documents being used to test the toolchain, a
significant amount of manual processing is required to publish the
RFCs with non-ASCII characters in the final text. In order to keep
...
Out of curiosity: as the current version of xml2rfc produces the UTF-8
plain text just fine (*), what additional processing are you referring
to?
There are the manual checks to determine if everything renders exactly
as expected. There are a number of discussions as we learn how to deal
Ok.
with half- and full-width characters in the same document, and try to
determine the best path forward to make such characters in tables to
line up properly. There are even more discussions as we learn more about
Seriously: don't bother.
invisible space characters outside of the ASCII realm and try to
understand if those are something we need to write scripts to identify.
If this is understood to be a problem, let's have a script that checks
for these characters.
xml2rfc is just one component of getting these documents published.
> ...
Understood.
Now what does this mean for drafts being written right now, and which
are not expected to be ready for publication in the next, let's say,
12 months? Can we start submitting I-Ds with non-ASCII characters
right now (without getting stopped by id-nits...)?
That's an excellent question. I think this is something to discuss with
both the IESG and the Tools Team, though I am fairly confident that
"right now" isn't possible. An idnits update is one of the tools
contracted for, and is not yet complete (see the expected timeline here:
https://trac.tools.ietf.org/tools/ietfdb/wiki/FormatToolsPlan). Also,
Well, idnits s just advisory. All it can block is automatic submission.
(I wish it did not).
we've seen that the datatracker isn't rendering non-ASCII characters
correctly in the PDF automatically generated from RFC 8187
(https://trac.tools.ietf.org/tools/ietfdb/ticket/2370). So, there is
still some work to do before this will all work.
Looking at the PDF linked from the datatracker
(<https://www.rfc-editor.org/rfc/pdfrfc/rfc8187.txt.pdf>), I don't see a
problem.
That said: I don't think that a minor bug in a conversion tool for a
supplemental output format is sufficient reason to block progress...
Best regards, Julian