Subject: Re: FTP and file transfers

From: Joe Touch <[email-masked]>
Date: Wed, 4 Oct 2017 06:05:47 -0700

On 9/29/2017 7:48 AM, Phillip Hallam-Baker wrote:
> How strange, I have always found FTP to be an absolute dog of a
> protocol precisely because it mandates idiot defaults and
> implementations are required to perform heuristic hacks. I always used
> to have to transmit files twice because the first time the transfer
> would be corrupted by the default being 'trash my data in case I am
> using an IBM machine'.
>
> The separation of the command and data is a good one but separating it
> over separate TCP/IP streams is an utter disaster for reliability.
> None of the FTPS clients I have found for Windows is able to reliably
> transmit a Web site update.

HTTP ignored this at their own peril, and ended up creating its own
multiplexing layer to avoid HOL blocking and support signalling and
reinventing parts of FTP poorly, IMO.

Faults in the implementation of Windows software are far too easy to
find to blame them on the protocol itself.

Joe

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 04 Oct 2017 16:15:26 +0100

> reinventing parts of FTP poorly, IMO.

there are some design philosophy problems here.  With tcp, you either
have inline stream signaling with inline multiplexing, or else you can
have out-of-band/multiband signaling, which will generally mandate
codification of endpoint identifiers inside the signaling stream.
Neither system is good.

QUIC sets out to solve both of these problems by moving away from TCP,
which is an approach worth learning from, but not without its problems.

> find to blame them on the protocol itself.

I'm with Phillip on this one: the ftp protocol is awful, from the points
of view of design, implementation and operations.

Nick

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Oct 2017 11:50:36 -0400

--On Wednesday, October 4, 2017 06:05 -0700 Joe Touch
<[email-masked]> wrote:

>> How strange, I have always found FTP to be an absolute dog of
>> a protocol precisely because it mandates idiot defaults and
>> implementations are required to perform heuristic hacks. I
>> always used to have to transmit files twice because the first
>> time the transfer would be corrupted by the default being
>> 'trash my data in case I am using an IBM machine'.
>> 
>> The separation of the command and data is a good one but
>> separating it over separate TCP/IP streams is an utter
>> disaster for reliability. None of the FTPS clients I have
>> found for Windows is able to reliably transmit a Web site
>> update.
> 
> HTTP ignored this at their own peril, and ended up creating
> its own multiplexing layer to avoid HOL blocking and support
> signalling and reinventing parts of FTP poorly, IMO.
> 
> Faults in the implementation of Windows software are far too
> easy to find to blame them on the protocol itself.

And that is a specific, and IMO helpful, example of the point I
was trying to make.   We would do well to look carefully at
protocols like FTP (and even, e.g., Archie, Gopher and WAIS) to
see what can be learned from them rather than saying "It, or
implementations of it, won't do XYZ well, therefore it is
hopelessly obsolete and should be abandoned or deprecated".
Similarly, rather than saying what amounts to "ABC (typically
'the web') has won and everything else is irrelevant" --a claim
I've even heard relative to lower-layer protocols not needed to
directly support HTTP/HTTPS-- we should be asking whether there
are problems, even niche problems, that can be better addressed
in other ways.  

We might even end up with a richer and more diverse and useful
Internet.

    john

---

From: Keith Moore <[email-masked]>
Date: Fri, 6 Oct 2017 23:23:02 -0400

There are still a number of important edge cases for which FTP is 
superior to any other widely available protocol - wildcard transfers of 
multiple files, text file transfers between systems with different 
character encoding conventions, 3rd party mediated transfers (used 
regularly in the broadcast TV industry where having system A control 
moving of content from B to C is exactly what is needed).

However FTP does look a bit antiquated by now - what with its support 
for file and record types that are almost (but not quite) entirely 
nonexistent on modern systems; a lot of implementations sadly never 
figured out how to make it work through NAT [*] (or a lot of ALGs in NAT 
didn't work right); and I have a hard time recommending for widespread 
use any protocol that doesn't have encryption as an ordinary, 
widely-implemented feature.

By this time, FTP's main virtue might be that it's been around so long 
that almost every system in existence supports an implementation of it, 
which is not the same thing as saying that most implementations of FTP 
are well-written.   But this is a virtue - being able to effectively 
transfer files between any pair of systems (including between old and 
new systems) is useful even given FTP's limitations.   HTTP 
implementations don't do this in practice at all, sftp/sshfs (while 
amazingly useful) isn't either standard or nearly so widely deployed, 
rsync is and always has been a mess, the various file system access 
protocols (NFS/CIFS/etc.) are very problematic to use.

But I'd really like it if we had something better, that would eventually 
enjoy the same level of deployment as FTP.   My bet is that sftp/sshfs 
is the most likely replacement, but it would need to be picked up again 
and some issues resolved.

Keith

[*]  (Of course, not working through NAT could be regarded as a feature 
- but sadly not one that has caused people to ditch NAT.)

On 09/29/2017 10:48 AM, Phillip Hallam-Baker wrote:
> There are much better options, rsync and STFP (SSH FTP) do work well 
> but unfortunately the hosting provider does not support them which is 
> why I am leaving my current provider when I get round to it.
>
> FTP to HISTORIC. The time has come.
>
>
> On Thu, Sep 28, 2017 at 6:45 PM, John C Klensin <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     --On Thursday, September 28, 2017 09:57 +0100 "tom p."
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     > The obvious one, which disrupts my work, is the Date Created.
>     > FTP gives me date which is, or is close to, the creation date
>     > of the RFC by the RFC Editor.
>     >
>     > Internet Explorer makes the Date Created the date on which I
>     > perform the download, which may be years later and so
>     > thoroughly misleading (to me).
>     >
>     > So standalone FTP every time.
>
>     Because FTP, by design, has a command in the protocol to
>     transmit a data type (primitive version of content type) and a
>     canonical form for text on the wire, competent implementations
>     are also capable of delivering files with EOL conventions, and
>     even character encodings, appropriate to the receiving
>     environment.  We learned lessons a _very_ long time ago from
>     EBCDIC and two (or, depending on how you count, at least four)
>     different encoding forms for ASCII that lead to that feature and
>     the TYPE command.
>
>     Perhaps unfortunately from where we stand today, the community
>     effectively decided to discard that feature, with a number of
>     client implementations deciding that binary transfers (in
>     FTP-speak, TYPE I) were enough that that receiving systems
>     should just get exact copies of whatever the sending system had
>     and sort it out themselves, in the process ignoring the FTP
>     requirement [RFC959, Section 4.1.2, "Representation Type"] that
>     the default in TYPE is not specified is ASCII non-print. While
>     TFTP [RFC1350] has a similar feature ("netascii" mode), AFAIK,
>     other FTP alternatives for transferring data under different
>     conditions, including SFTP over SSH and Rsync, simply assume
>     image copies are fine.
>
>     Trying to transfer files containing non-ASCII characters makes
>     the problem worse because, while the spec isn't explicit about
>     it, an FTP implementation should presumably fail if TYPE A is
>     used and the contents of the data file cannot be interpreted as
>     ASCII.  Attempts to add a "TYPE U" (for "Unicode" or "UTF-8") to
>     FTP to solve that problem for another canonical text
>     representation have gotten absolutely no problem, leading me to
>     presume that the community has completely lost interest in these
>     issues.
>
>     Someone who believed in the existence of character coding and
>     transmission deities and divine retribution from them might
>     conclude that the community deserves this BOM mess, along with
>     UTF-16 on the wire, as a result of not dealing with the issue
>     effectively in FTP, TFTP, and a variety of other transfer
>     measures.  I couldn't possibly comment on that.
>
>         john
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Oct 2017 18:58:28 -0400

On Fri, Oct 6, 2017 at 11:23 PM, Keith Moore <[email-masked]>
wrote:

> There are still a number of important edge cases for which FTP is superior
> to any other widely available protocol - wildcard transfers of multiple
> files, text file transfers between systems with different character
> encoding conventions, 3rd party mediated transfers (used regularly in the
> broadcast TV industry where having system A control moving of content from
> B to C is exactly what is needed).
>
> However FTP does look a bit antiquated by now - what with its support for
> file and record types that are almost (but not quite) entirely nonexistent
> on modern systems; a lot of implementations sadly never figured out how to
> make it work through NAT [*] (or a lot of ALGs in NAT didn't work right);
> and I have a hard time recommending for widespread use any protocol that
> doesn't have encryption as an ordinary, widely-implemented feature.
>
​Exactly how I feel. Yes, it was state of the art in its day. It is not
state of the art now. I would like something better and as you point out,
the alternatives are not exactly great.​

​I blame you for the following Keith.​ It occurred to me that there is a
much better solution and I already have the pieces.

​These days, I don't actually do much actual 'file transfer' so much as
want to synchronize two directories. Often what I would like is to achieve
an instantaneous cut over so that one microsecond, the contents of the
directory is { A, B, C } ​and the next it is { A, C', D } and no
inconsistency occurs between those two points.

It is the same with distribution of software updates. I have to wait 5
minutes while the machine downloads and applies an update? REALLY? How
quaint.

This week I have been playing with a new container format that has the
novel idea of having a length indicator at the front and the back of every
data frame. This means that it is just as quick to read frames backwards
from the end as it is forwards from the start. And then I added a binary
tree and a Merkel tree for good measure.

The basic idea is similar to a Zip file, you write the file out
sequentially and then drop the index on the end when complete. Only with
this scheme you can drop a series of incremental indexes as you go along.
Upshot is that you can extract any record on arbitrary search criteria in
log2(n) time without startup overhead.

So one reason for doing this is to support efficient mail message etc
stores even with end to end encryption.

But another purpose is to enable two log files to be synchronized. Updates
written to one are appended to the other.

What I didn't think of but would be entirely logical, is a scheme in which
the container file I write out does not have any data in it, that is
written out to the file system instead. I could then use the container file
as the basis for synchronizing two directories on different machines.

---

From: Doug Royer <[email-masked]>
Date: Sat, 7 Oct 2017 19:50:18 -0600

On 10/07/2017 04:58 PM, Phillip Hallam-Baker wrote:
> On Fri, Oct 6, 2017 at 11:23 PM, Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     superior to any other widely available protocol - wildcard transfers
>     of multiple files, text file transfers between systems with
>     different character encoding conventions, 3rd party mediated
>     transfers (used regularly in the broadcast TV industry where having
>     system A control moving of content from B to C is exactly what is
>     needed).
> 
>     However FTP does look a bit antiquated by now - what with its
>     support for file and record types that are almost (but not quite)
>     entirely nonexistent on modern systems; a lot of implementations
>     sadly never figured out how to make it work through NAT [*] (or a
>     lot of ALGs in NAT didn't work right); and I have a hard time
>     recommending for widespread use any protocol that doesn't have
>     encryption as an ordinary, widely-implemented feature.
> 
> state of the art now. I would like something better and as you point 
> out, the alternatives are not exactly great.​

rsync works for synchronization, and subdirectories (and the IETF 
already has rsync available). And it can run with SSH.

-- 

Doug Royer - (http://DougRoyer.US  http://goo.gl/yrxJTu )
[email-masked]
714-989-6135

---

From: Keith Moore <[email-masked]>
Date: Sun, 8 Oct 2017 23:59:22 -0400

You have it backwards - the broken shards are the NATted IPv4 
Internet.   Not completely useless, but much less functional than the 
Internet should be, and impeding a transition to a much more functional one.

On 09/18/2017 06:17 PM, Adam Roach wrote:
> If you want to reduce this to analogies, your proposal is much closer 
> to the situation we had in the IETF a couple of decades ago when it 
> came to NATs: we preferred architecturally pristine approaches that 
> shattered into useless, broken shards on contact with reality.

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Oct 2017 00:11:26 -0400

I must say that I'm very disappointed by this development.   I'm NOT 
disappointed by the efforts to represent non-ASCII names and other text 
faithfully in documents.

What bugs me is that the ASCII RFC format was, by careful choices of 
character encoding, line lengths, page lengths, and placement of form 
feeds, designed to be maximally readable on as many existing systems as 
possible.  By contrast, the UTF8 RFC format subverts that goal in favor 
of being able to represent names and non-English text faithfully in 
bits, only to have them be rendered unfaithfully by a great many 
present-day applications.

Having a UTF8 RFC format wouldn't have bothered me, having UTF8 replace 
the ASCII format bothers me much more.   It's hard to escape the 
impression that being "fair" has become more important than having the 
technical content of RFCs be readable.

Keith

On 09/14/2017 05:07 PM, Heather Flanagan (RFC Series Editor) wrote:
> Hello all,
>
> RFC 8187, "Indicating Character Encoding and Language for HTTP Header
> Field Parameters", is the first RFC to be published with UTF-8 encoding
> and include characters not in the basic ASCII character set. This
> document has been, with the author's consent, patience, and support,
> used to test the existing tool chain to produce RFCs to see where the
> environment has difficulty in handling non-ASCII characters. The RPC is
> continues this testing with the PRECIS document cluster (C326), which is
> currently in AUTH48.
>
> 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
> overall processing times down, leave staff enough time to test
> the other tools that are being developed as part of the RFC format
> project, and allow the editors time to create and/or update new
> procedures as the v3 tools are released, no additional non-ASCII
> documents outside of RFC 8187 and the PRECIS cluster will be published
> until the new format tools are in production.
>
> Many thanks go out to Julian Reschke and Peter Saint-Andre for their
> support, the Tools Team for answering a variety of technical questions,
> and to the RPC staff who worked to ensure that the RFC
> publication process resulted in readable RFCs.
>
>
> Heather Flanagan, RSE
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 09 Oct 2017 16:01:18 +0900

> Internet should be, and impeding a transition to a much more

keith, there is a problem with your email system.  it is regurgitating
messages from the late 1990s.  what is strange is that they have current
dates.

randy

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Oct 2017 07:05:31 -0400

> messages from the late 1990s.  what is strange is that they have current
Hmm.  That would explain why I occasionally see mail from people who 
haven't learned from the past 20 years.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Mon, 9 Oct 2017 13:09:32 +0200

> haven't learned from the past 20 years.

I don't believe its explanation, its merely correlation.

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Oct 2017 13:14:52 -0400

Sorry for the delay -- catching up on this thread after
temporarily giving up on it.

--On Wednesday, September 27, 2017 08:38 +1300 Brian E Carpenter
<[email-masked]> wrote:

> So why don't we, the Internet standards people who believe in
> rough consensus and running code, request the RFC Editor (a
> friend of ours) to supply two text versions of each RFC, like
> 
> https://www.rfc-editor.org/rfc/rfc8187.txt   as today, with
> BOM if relevant 
> https://www.rfc-editor.org/rfc/rfc8187.ut8
> containing pure UTF-8 with no BOM ever

If one were really going to do that, one would need three
representations (pick your own three-character suffixes for the
first two):

	rfc8176.utf8   (standard/normal Unicode in UTF-8, no BOM)
	rfc8176.utf8-with-BOM (as above, but...)
	rfc8176.txt    (ASCII, with characters outside the ASCII
repertoire expressed as \u'[N[N]]NNNN' (see RFC 5137) or
another escaping system of the RFC Editor's choice.
Note that there is no  good reason to assume that a text
file that contains octets outside the ASCII range is
UTF-8, especially if the creation date is unknown.
Historically, it could as easily be encoded as specified
in one of ISO/IEC 8859-X standards, some proprietary
code page, etc.)

Because "\u'2639'" requires significantly more horizontal space
than "☹", the txt form with escapes would require some
reformatting, but the native XML idea will solve all those
problems, right?

     john

---

From: "John Levine" <[email-masked]>
Date: 9 Oct 2017 18:59:05 -0000

>present-day applications.

Can you give us some examples of these present-day applications that
don't handle UTF-8?

My experience is quite the opposite: anything written in the past
decade handles UTF-8 just fine.  It's not like I'm running cutting
edge stuff, I look at RFCs using "more" in a shell window.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Oct 2017 15:55:19 -0400

Essentially every single time I need to deal with a document containing utf8, I see glitches.  It's not every single app but there's always some app.  

Sent from my iPhone

> On Oct 9, 2017, at 2:59 PM, John Levine <[email-masked]> wrote:
>

---

From: "John R Levine" <[email-masked]>
Date: 9 Oct 2017 15:58:26 -0400

> Essentially every single time I need to deal with a document containing utf8, I see glitches.  It's not every single app but there's always some app.

No, really, please give us some concrete examples.

"Random programs on Keith's PC" isn't very helpful.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Mon, 9 Oct 2017 16:04:04 -0400

I am far too busy this week to research this and get back to you with details.  And I suspect that neither your computers nor mine are representative of those of RFC readers.  But there are so many things that have to work right for UTF8 to display and print correctly that I'm still amazed that it ever works, so am unsurprised when it doesn't.  It's the normal state of brain damage as far as I'm concerned.  It's just sad that IETF is now apparently saddled with it.

Sent from my iPhone

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Oct 2017 20:15:10 +0000

On Mon, Oct 09, 2017 at 04:04:04PM -0400, Keith Moore wrote:

> I am far too busy this week to research this and get back to you with
> details.  And I suspect that neither your computers nor mine are
> representative of those of RFC readers.  But there are so many things that
> have to work right for UTF8 to display and print correctly that I'm still
> amazed that it ever works, so am unsurprised when it doesn't.  It's the
> normal state of brain damage as far as I'm concerned.  It's just sad that
> IETF is now apparently saddled with it.

Now that I always use a UTF-8 charset locale (LC_CTYPE=en_US.UTF-8),
UTF-8 *just works* all the time.  What does not work well, is other
non-ascii charsets, as when I look at whois data from registries
that for reason still return iso-8859-1 instead of UTF-8.

Platforms where UTF-8 does not just work are the past, and it is
time to move on.

-- 
	Viktor.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Oct 2017 10:25:23 +1300

> another escaping system of the RFC Editor's choice.

I see your logic, but pragmatically today the implication of ".txt"
is not "pure ASCII", but rather "possibly ASCII, or possibly
UTF-8 if there's a BOM, or possibly some other random choice of
coded character set." There's very little to be done about the
third case, so I'm arguing for the second one as the lowest
common denominator of sorts.

"pure ASCII with some convention for Unicode escapes" might be
a good idea too, but I don't quite see how to get there from
here.

Regards,
    Brian

---

From: "Heather Flanagan (RFC Series Editor)" <[email-masked]>
Date: Mon, 9 Oct 2017 16:36:08 -0700

> another escaping system of the RFC Editor's choice.

A few points to consider. First, the RFC Editor will review, at least to
some extent, every file we produce, and our tools will need to be
modified to create the additional formats; that complexity would then
need to be maintained going forward. The more files added, the more
resources it will take to produce. This has implications for either the
time it takes to publish or the cost it takes to publish. Second, there
have also been some discussions about creating separate files for
paginated versus unpaginated text files. That would take us up to six
files just for the plain-text outputs (noting the RFC Editor also has
the PDF/A-3 and HTML to review).

Alternatively, the IETF community that prefers plain text can develop
tools that takes the one file created by the RFC Editor and strip the
BOM, add pagination, or run it through a translation tool to get it in
their native language--these will not be produced or reviewed by the RFC
Editor, but will perhaps meet the individual desires here. Given the
number of options, opinions, and resources involved, I think this makes
the most sense.

-Heather

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Oct 2017 22:29:34 -0400

--On Monday, October 9, 2017 16:36 -0700 "Heather Flanagan (RFC
Series Editor)" <[email-masked]> wrote:

>> --On Wednesday, September 27, 2017 08:38 +1300 Brian E
>> Carpenter <[email-masked]> wrote:
>> 
>> representations (pick your own three-character suffixes for
>> the first two):
>> 
> A few points to consider. First, the RFC Editor will review,
> at least to some extent, every file we produce, and our tools
> will need to be modified to create the additional formats;
> that complexity would then need to be maintained going
> forward. The more files added, the more resources it will take
> to produce. This has implications for either the time it takes
> to publish or the cost it takes to publish. Second, there have
> also been some discussions about creating separate files for
> paginated versus unpaginated text files. That would take us up
> to six files just for the plain-text outputs (noting the RFC
> Editor also has the PDF/A-3 and HTML to review).
> 
> Alternatively, the IETF community that prefers plain text can
> develop tools that takes the one file created by the RFC
> Editor and strip the BOM, add pagination, or run it through a
> translation tool to get it in their native language--these
> will not be produced or reviewed by the RFC Editor, but will
> perhaps meet the individual desires here. Given the number of
> options, opinions, and resources involved, I think this makes
> the most sense.

Up to a point, yes.  On the other hand, unless the RFC Editor
intends to make a rule requiring either that sections (or
subsections) not extend over circa a page, or numbering lines,
or doing something else that facilities references into a
document, I think you'd best retain a canonical / distributed
version with page numbers, headers, and footers.  That
information is a lot easier to remove than it is to reliably add.

Sorry I wasn't more clear that the suggestion above was a bit
tongue in cheek for more or less the reasons you identify.   But
I am concerned about the use of "txt" to identify files that are
not entirely ASCII.  The reasons have to do with guessing at
encodings (a far more complex question than whether or not there
are octets present that might be a BOM) and have, IMO, been
discussed (at great length) elsewhere.

    john

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Oct 2017 21:48:57 +0300

> On 10 Oct 2017, at 5:29, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> Series Editor)" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> version with page numbers, headers, and footers.  

In that case we’d all have to look up that version whenever we received a reference to something in RFC xxxx page 7. So even if it’s more comfortable for us to read the RFC in a browser or on a phone, we’d need access to this canonical version.

IMO it’s far easier to reference section and paragraph number, as in “the formula in RFC 6962, section 2.1.2, paragraph 3”. This works with any format, paginated or not.

This gets clunky if people have 4-page long paragraphs or 50-paragraph sections, but that kind of badness can and should be caught by working groups, shepherd reviews or if all else fails, gen-art reviews.  This one is not up to the RFC editor to make rules against.

Yoav

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 10 Oct 2017 16:06:54 -0400

We could, of course, introduce paragraph numbering in the left margin,
which would alleviate the page number reference problem since as Yoav
notes, we’ll no longer have constant page numbers in the various display
versions of an RFC.

Cheers,
Andy

On Tue, Oct 10, 2017 at 2:48 PM, Yoav Nir <[email-masked]> wrote:

> In that case we’d all have to look up that version whenever we received a
> reference to something in RFC xxxx page 7. So even if it’s more comfortable
> for us to read the RFC in a browser or on a phone, we’d need access to this
> canonical version.
>
> IMO it’s far easier to reference section and paragraph number, as in “the
> formula in RFC 6962, section 2.1.2, paragraph 3”. This works with any
> format, paginated or not.
>
> This gets clunky if people have 4-page long paragraphs or 50-paragraph
> sections, but that kind of badness can and should be caught by working
> groups, shepherd reviews or if all else fails, gen-art reviews.  This one
> is not up to the RFC editor to make rules against.
>
> Yoav
>
>
>

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2017 21:57:00 -0000

>information is a lot easier to remove than it is to reliably add.

I think that when this came up before, the conclusion was that the
canonical references would be to section numbers and paragraphs.
There are a lot of ways to print out a document, e.g., our heritage
line printer emulation, XML direct to PDF, XML to HTML to printer via
various browsers, all of which will produce different pagination.  And
of course there's North American paper sizes vs. A4, and dynamic
pagnization for screens on various devices

If the way to find page numbers is to go find the line printer version
and cross reference that to the version of the document I actually
use, I expect I am not the only person who won't.

On the third hand, if people really like page numbers, it wouldn't be
hard to add an XML element that says page N starts here.  But I don't
think we like page numbers that much.

R's,
John

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Oct 2017 10:12:53 +0100

That is popular in legal circles and I find it so distracting. In those 
circles distraction of the reader may be good for the author. However 
our goal is clarity of message to both so we can write and implement 
unambiguous specifications.

When doing reviews I also find it useful to have page numbers as a quick 
way of knowing how much text I need to make time to read.

- Stewart

On 10/10/2017 21:06, Andrew G. Malis wrote:
> notes, we’ll no longer have constant page numbers in the various 
> display versions of an RFC.
>
> Cheers,
> Andy
>
>
> On Tue, Oct 10, 2017 at 2:48 PM, Yoav Nir <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     On 10 Oct 2017, at 5:29, John C Klensin <[email-masked]
>>>>     Carpenter <[email-masked]
>>>>     <mailto:[email-masked]>> wrote:
>>>>
>>>>>     https://www.rfc-editor.org/rfc/rfc8187.txt
>>>>>     <https://www.rfc-editor.org/rfc/rfc8187.txt>   as today, with
>>>>>     BOM if relevant
>>>>>     <https://www.rfc-editor.org/rfc/rfc8187.ut8>
>     In that case we’d all have to look up that version whenever we
>     received a reference to something in RFC xxxx page 7. So even if
>     it’s more comfortable for us to read the RFC in a browser or on a
>     phone, we’d need access to this canonical version.
>
>     IMO it’s far easier to reference section and paragraph number, as
>     in “the formula in RFC 6962, section 2.1.2, paragraph 3”. This
>     works with any format, paginated or not.
>
>     This gets clunky if people have 4-page long paragraphs or
>     50-paragraph sections, but that kind of badness can and should be
>     caught by working groups, shepherd reviews or if all else fails,
>     gen-art reviews. This one is not up to the RFC editor to make
>     rules against.
>
>     Yoav
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Oct 2017 10:45:52 -0400

Personally, I find page references to be really confusing when people 
talk about RFCs.  But personal preference is not what matters.

We have already agreed that within the near future the pagination of 
RFCs will differ in different representations, and some may not have 
pagination at all.
As such, worrying about keeping page numbers working for the next few 
years while we transition seems a less than effective use of our resources.

Yours,
Joel

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Oct 2017 12:26:48 +0200

On 14/09/2017, Heather Flanagan (RFC Series Editor) <[email-masked]> wrote:

> the first RFC to be published with UTF-8 encoding and include characters not in the
> basic ASCII character set.

Interesting, and a quick sanity test with
https://tools.ietf.org/html/rfc8187 works for me (= can see an € in
3.2.3), that should also cover all WikiMedia and MediaWiki projects
linking to tools.ietf.org (not limited to RFCs, I-Ds are also often
linked via tools.ietf.org). So now I can finally replace an ancient
copy of vintage 2005 draft-hoffman-utf8-rfcs-01.txt by a more up to
date RFC 8140 ;-)

Skeptical, maybe the Unicode emoji for ;-) does not yet work
everywhere, some folks including me are still using Windows 7 and not
planning to upgrade before 2020.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 24 Oct 2017 15:29:50 +0200

On 2017-09-22 18:54, Heather Flanagan (RFC Series Editor) wrote:
> ...
> 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,
 > ...

Currently says "End of January". Note that all I'm asking for is a way 
to disable the "all ASCII" check.

> 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.

FWIW, this is not about the PDF (which is fine), but the fact that 
datatrackers's TXT-to-HTML conversion doesn't work properly (in contract 
to the one used for the HTML on tools.ietf.org).

It would be awesome to see some progress here.

Best regards, Julian

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 24 Oct 2017 16:41:58 +0200

Hi Julian,

> to disable the "all ASCII" check.

It should be feasible to tweak the current idnits in this respect -- but
that's going to permit non-ascii in a lot of places where the exact rules
would not permit non-ascii.  Better checks will still have to wait for the
new idnits.

> It would be awesome to see some progress here.

It's on my to-do list, but not at the very top.  Will see what I can do.

Best regards,

	Henrik