Subject: [rfc-i] Bug in RFC Search page...

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Sep 2017 08:30:03 +1300

https://www.rfc-editor.org/search/rfc_search_detail.php?rfc=8187&pubstatus%5B%5D=Any&pub_date_type=any

This returns a result mentioning an "ASCII" version of the RFC. There is no ASCII
version of RFC 8187.

(According to some people, there is no UTF-8 version either because of the BOM.)

Regards
   Brian

_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Sep 2017 22:33:29 +0200

> This returns a result mentioning an "ASCII" version of the RFC. There is no ASCII

I think we just need to stop calling plain-text ASCII.

(Note that the HTML versions of many documents are ASCII.)

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 26 Sep 2017 22:41:42 +0200

What terminology do you propose

ASCII text -> plain-text
UTF-8 text -> plain-text unicode
HTML ASCII -> HTML
HTML UTF-8 -> HTML unicode
...

?

(as a reminder because i didn't get any response, i would love to see an RFC header
 field indicating the format of the document... ;-)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 Sep 2017 22:49:56 +0200

> On Sep 26, 2017, at 22:41, Toerless Eckert <[email-masked]> wrote:
> 

Well, both are plain-text, and both are unicode.
Plain-text-beyond-ascii would be more like it for the second, but why call that out.
(And no, we don’t need a third category Plain-text-beyond-the-basic-multilingual-plane, or Plain-text-with-astral for short.)

> HTML UTF-8 -> HTML unicode

I don’t think that distinction ever needs to be made, because HTML embeds metadata about its charset, and there are no real interop problems when you do that.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Sep 2017 10:04:23 +1300

> I think we just need to stop calling plain-text ASCII.

Sure, the first level fix is to change the result to say "plain text"
instead of "ASCII". We can't change it to say "UTF-8 text" without resolving
a little dispute about the BOM ;-).

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 26 Sep 2017 23:57:43 +0200

> Plain-text-beyond-ascii would be more like it for the second, but why call that out.

There is a lot of tool chains out there that will not render UTF-8 correctly,
therefore it is IMHO extremely viable to have a clear indication of the
minimum toolchain features required to render a document correctly (in the first
page header of an RFC wold be great).

Also: As long as the "minimum rendering" features of documents are not explicitly
noted in human readable form anywhere, we do not need to define a terminology.

> (And no, we don???t need a third category Plain-text-beyond-the-basic-multilingual-plane, or Plain-text-with-astral for short.)

Not sure what you are referring to "More UTF-8 characters than possible with iso8859" ?
Given how we should not publish text-only documents other than ascii or UTF-8, i think we can happily
ignore those legacy options.

> I don???t think that distinction ever needs to be made, because HTML embeds metadata about its charset, and there are no real interop problems when you do that.

Given how browsers are quite inconsistent in the characer sets they load, it would be nice to have explicit indication of the character sets required to render a document. I've seen PDF documents where i had to go to page 100 before some crucial text was not rendered because it used some character set not available to me.

> Grüße, Carsten
     ^
https://en.wikipedia.org/wiki/Capital_%E1%BA%9E

Oh, the innovation...

---
[email-masked]

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 27 Sep 2017 08:32:15 +1000

On 27 Sep. 2017 07:58, "Toerless Eckert" <[email-masked]> wrote:

> (And no, we don???t need a third category Plain-text-beyond-the-basic-multilingual-plane,
or Plain-text-with-astral for short.)

Not sure what you are referring to "More UTF-8 characters than possible
with iso8859" ?
Given how we should not publish text-only documents other than ascii or
UTF-8, i think we can happily
ignore those legacy options.

Emoji are astral codepoints, aren't they? 🤞🏻

> I don???t think that distinction ever needs to be made, because HTML
embeds metadata about its charset, and there are no real interop problems
when you do that.

Given how browsers are quite inconsistent in the characer sets they load,
it would be nice to have explicit indication of the character sets required
to render a document. I've seen PDF documents where i had to go to page 100
before some crucial text was not rendered because it used some character
set not available to me.

If you mean font support (I'm not going to trip myself up over the
difference between character sets and encodings and all that, but I'm
pretty sure 'Unicode' has you covered for characters/codepoints) that's a
mostly-solved problem in the modern web, with webfonts and the like.

So the useful words to put in the table would be basic document types
(PDF/text/HTML). We can bicker over what "text" means WRT UTF-8 elsewhere.

Cheers
-- 
Matthew Kerwin

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Sep 2017 01:47:40 +0200

On Wed, Sep 27, 2017 at 08:32:15AM +1000, Matthew Kerwin wrote:
> Emoji are astral codepoints, aren't they? ????????

Thanks!

> mostly-solved problem in the modern web, with webfonts and the like.

Sure, sitting in an airplane, trying to read a document and getting a
pop-up window to go on the internet, create i think an apple-id to
be able to download some asian character set (if i remember it correctly). 

> (PDF/text/HTML). We can bicker over what "text" means WRT UTF-8 elsewhere.

I definitely would like to have an indication if it's "more than ASCII" text
(eg: foreign characters included).

Cheers
    Toerless

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 27 Sep 2017 10:32:32 +1000

> be able to download some asian character set (if i remember it correctly).
​I don't know about PDFs, but if you download the HTML version of a page
there's usually an option to download all the linked resources (images,
CSS, etc.) at the same time, so it should continue to work offline.
Although, I don't know if that includes fonts linked from CSS.​

> (eg: foreign characters included).
​Sure, I can understand the need for a multidimensional "requirements for
accurately viewing this resource" description.  Soon enough it will have to
be able to describe the basic format (PDF/HTML/plain text), the character
range (7-bit ASCII, Latin-1[*], BMP, Supplementary[†]), and whether it
includes embedded images.  A single-word description probably isn't enough,
though.

Meanwhile, I figured the words in that column were basically representative
of the formats described in RFC 7990 (and its antecedents.)  In which case,
all the rest is implied.

Cheers

[*] i.e. the Basic Latin + Latin-1 Supplement blocks; same as ISO-8859-1

[†] Some tools still have issues with characters that don't fit in UCS-2.
There's also "includes four-byte UTF-8 sequences" which is a different
thing, but has caused me issues in the past with some tools.​
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 27 Sep 2017 20:04:01 +0200

On Wed, Sep 27, 2017 at 05:53:48PM -0000, John Levine wrote:
> Those are buggy PDFs.  A PDF is supposed to contain all the fonts it
> uses beyond a small standard set, but there is a lot of PDF crudware
> that wrongly assumes that whatever fonts it finds on the machine where
> it's running will exist everywhere.  

I have stopped trying to really understand all those details for the last
two decades, but i fear what you describe sounds like the original intention
of adobe when they thought fonts embedded in PDFs could not be extracted
and (illegally) be reused outside of the PDF. Once that hack happened (2 decades ago ?),
the problem of licensed/payware fonts and their use has AFAIK lead to
less inclusion of fonts into PDF.

> Hey, maybe we could put a couple of bytes at the begining that say
> this is a UTF-8 document.

I smell a BOM joke, even though i do not even WANT TO understand that stuff and nuked that thread.

There are enough people taking care of making documents more machine friendly.
I only care about the elements that make them more human friendly ;-)

Cheers
    Toerless

---

From: "John Levine" <[email-masked]>
Date: 27 Sep 2017 17:53:48 -0000

In article <[email-masked]> you write:
>Given how browsers are quite inconsistent in the characer sets they load, it would be nice to have explicit indication
>of the character sets required to render a document. I've seen PDF documents where i had to go to page 100 before some
>crucial text was not rendered because it used some character set not available to me.

R's,
John