[rfc-i] draft-iab-rfc-nonascii-00

Heather Flanagan (RFC Series Editor) rse at rfc-editor.org
Mon Feb 29 10:46:30 PST 2016


On 2/28/16 10:35 AM, Julian Reschke wrote:
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.abstract>:
> 
> 
> "This document updates RFC 7322. ..."
> 
> ...but doesn't so in the op block.

Fixed in -01

> 
> "... Please review the PDF version of this draft."
> 
> I'd move that into a separate note; it doesn't belong into the abstract.
> 
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.1.p.2>:

At least for now, I think it belongs in as many places as possible to
get people to review the correct document.

> 
> 
> "For much of the history of the RFC Series, the character encoding used
> for RFCs has been ASCII [ANSI.X3-4.1986].  ..."
> 
> I believe the now preferred reference is RFC 20.
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.1.p.6>:
> 

OK. Will fix in -02.

> 
> "... Other implementers must not expect those changes to remain
> backwards-compatible with the details described this document."
> 
> ...described *in* this document.
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.2>:

OK. Will fix in -02.

> 
> 
> "Searches against RFC indexes and database tables need to return
> expected results and support appropriate Unicode string matching
> behaviors;"
> 
> It's not clear what that means, in particular unless we define expected
> results.

People expect search engines to be able to perform searches such that
searching on "GEANT", for example, will return matches for both "GEANT"
and "GÉANT". The reverse would also be true. I expect this is
established enough behavior that we do not need to define it in more
detail (insert implied question here).

> 
> "People whose system does not have the fonts needed to display a
> particular RFC need to be able to read the various publication formats
> and the XML correctly in order to understand and implement the
> information described in the document."
> 
> Maybe "will have to read alternative publication formats"?
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3>:

Will fix in -02.

> 
> 
> "This section describes the guidelines for the use of non-ASCII
> characters in the header, body, and reference sections of an RFC."
> 
> Are there other sections? What about the index, for instance?
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3.1.p.3>:

I shall have to think on this one. I don't specify the ToC or
Appendices, either.

> 
> 
> "Example of non-ASCII characters that do not require escaping [RFC4475]:"
> 
> It would be good to concretely reference the relevant part of RFC 4475,
> and to state how the example below differs from it.
> 
> Such as: "Example of non-ASCII characters that do not require escaping
> (the example from Section 3.1.1.12 of [RFC4475], with a hex dump
> replaced by the actual character glyphs):"
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3.2.p.1>:
> 

I'll think on this one.

> 
> "Person names may appear in several places within an RFC. In all cases,
> valid Unicode is required."
> 
> What is the definition of "valid" Unicode? And doesn't it apply to all
> of the document, thus would be better called out once for all in the
> beginning?

This did cause me to find an interesting message thread from a few years
ago "Subject: RE: What does it mean to "not be a valid string in
Unicode"?"
<http://www.unicode.org/mail-arch/unicode-ml/y2013-m01/0034.html>. I
will talk to some of the i18n experts for some suggestions as to what,
if anything, needs to be done here.

> 
> "For names that include characters outside of the Unicode Latin and
> Latin Extended script, an author-provided, ASCII-only identifier is
> required to assist in search and indexing of the document."
> 
> It would be good to be more precise about what non-ASCII characters are
> allowed (range?).
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3.4.p.12>:
> 

My understanding is that "Latin Extended" is a reasonable way to capture
Basic Latin (ASCII)
Latin-1 Supplement
Latin Extended-A
Latin Extended-B
Latin Extended-C
Latin Extended-D
Latin Extended-E
Latin Extended Additional

> 
> "BCP 137, "ASCII Escaping of Unicode Character" describes the pros and
> cons of different options for identifying Unicode characters in an ASCII
> document BCP137 [RFC5137]."
> 
> So why do we cite [RFC5137]? Shouldn't his be [BCP137]?
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3.5.p.1>:

Yes. Will fix in -02.

> 
> 
> "Tables follow the same rules for identifiers and characters as in
> "Section 3.4. Body of the document"."
> 
> (this intra-document link should be an <xref> in the XML source)
> 
> <http://greenbytes.de/tech/webdav/draft-iab-rfc-nonascii-00.html#rfc.section.3.8.p.1>:
> 

Will fix in -02.

> 
> "Keywords and citation tags must be ASCII only."
> 
> What does "Keywords" refer to? The things we put into the xml2rfc
> <keyword> element?

Yes.

Thank you for the thorough review, Julian!
Heather



More information about the rfc-interest mailing list