RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
Marc I opened the link on two different devices, to see how the tables rendered. On one (iPod touch with Safari), it worked reasonably. The only problem was that the table columns were skewed due to browser not using monospace fonts. Were the table more complex or were there some truly wacky ASCII art it probably wouldn't have worked. On a second device (running a different browser, unnamed to protect the guilty) I received a continuous stream of characters with no line breaks at all. When viewing the txt version on www.rfc-editor.org that same browser does a fairly good job, assuming that I rotate the device to fit the table into the width. However, these 2 tables were small and relatively simple. Why don't you try Figure 3 of RFC 5087 or Figure 2 or 15 of RFC 5905 ? Y(J)S -Original Message- From: Marc Petit-Huguenin [mailto:petit...@acm.org] Sent: Sunday, November 27, 2011 18:20 To: Yaakov Stein Cc: Dave Aronson; IETF Discussion Subject: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. [1] Try this link: http://ietf.implementers.org/rfc5928.txt. The mime type should be text/lp. On 11/27/2011 12:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want*
RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt That is the worst option for my two devices. On both devices the line wraps distort the tables beyond recognition. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 01:52 AM, Yaakov Stein wrote: Marc I opened the link on two different devices, to see how the tables rendered. On one (iPod touch with Safari), it worked reasonably. The only problem was that the table columns were skewed due to browser not using monospace fonts. Were the table more complex or were there some truly wacky ASCII art it probably wouldn't have worked. On a second device (running a different browser, unnamed to protect the guilty) I received a continuous stream of characters with no line breaks at all. When viewing the txt version on www.rfc-editor.org that same browser does a fairly good job, assuming that I rotate the device to fit the table into the width. However, these 2 tables were small and relatively simple. Why don't you try Figure 3 of RFC 5087 or Figure 2 or 15 of RFC 5905 ? I added all the RFCs in all 3 directories, so you can now test with your favorite RFC. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7TwaMACgkQ9RoMZyVa61cAEwCfSoNZ0htfiOTnpXbceAEybW0U rOoAoIAd2Ad3b8+n5jzjPKFmkpejeArg =ONLn -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
On 2011-11-27 17:20, Marc Petit-Huguenin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. ... I think something is wrong if we seriously consider that writing new reader tools is the solution to whatever we think our problem is. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/28/2011 01:58 AM, Yaakov Stein wrote: That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt That is the worst option for my two devices. On both devices the line wraps distort the tables beyond recognition. Well, the point was that a browser or any other display application cannot detect that a specific text file is in fact a line-printer ready text file. This is why we propose to assign a mime type or a mime parameter, so (future) applications know how to present it. The first step is to let John know if you support doing this (and eventually if you have a preference between the 3 options). Then if the idea goes forward, we can start the work of modifying the applications so they render correctly this format. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7TwqcACgkQ9RoMZyVa61cEBACfeL+jaxH86JV7PE1YmDzqDAuK ZAEAn2XoUYFTjinfZuTLctF2MnAhp9kT =swso -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. [1] Try this link: http://ietf.implementers.org/rfc5928.txt. The mime type should be text/lp. On 11/27/2011 12:20 AM, Yaakov Stein wrote: Dave I agree that we are thinking as content creators, and that is the problem. The requirement is not that we will be able to write a new document in 50 years in the same format. The requirement is that we should be able to read the documents written 50 years before. The problem about ASCII art is not simply the monospacing. The main problem is the line wrapping. I have tried many times to look at ASCII art on iPhones, iPods, and even small pads. Once you zoom down sufficiently to get the lines not to break, the characters are no longer readable. For a screen size of about 60 mm, 80 character lines means that the characters are only 0.75mm in width. Even assuming a short figure that could be viewed rotated (width 110 mm) each character width would be only slightly more than the 1 mm needed for viewing, and less than the 1.5 mm needed for actual reading. Put in another way, high-end cellphone screens presently have 640 pixel widths. For 80 character layouts, this translates to 8 pixels per character plus inter-character spacing, or about 6 pixel character widths. Even were they visible (and each pixel is less than 1/10 of a mm!) this would mean very low quality fonts - 5*7 was the lowest quality used by old dot-matrix printers. And modern software is not optimized for readability at that font resolution. So, if we expect people to be able to read our documents in 5 years, let alone 50, we need to stop using ASCII art. Y(J)S -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave Aronson Sent: Sunday, November 27, 2011 00:10 To: IETF Discussion Subject: Re: discouraged by .docx was Re: Plagued by PPTX again On Sat, Nov 26, 2011 at 15:52, Yaakov Stein yaako...@rad.com wrote: ASCII is already unreadable on many popular devices Oh? For what reason? Sorry, I'm still using an incredibly stupid phone, so I may be behind the curve on such changes. As far as I've seen in my limited exposure, any difficulty is usually because it's often not linewrapped well (or at all), forcing a lot of horizontal scrolling, especially after being forced to be big enough to be legible on tiny screens not held right up to the face. That's rather inconvenient, but still a far cry from unreadable -- plus it's a problem with the reader program (being too featureless to rewrap the text), not anything inherent in the format. ASCII *artwork*, yes, that often gets ruined by the refusal of many programs to allow the user to display content in a monospaced font. But that's not because it's in plain ASCII; you could say the same thing of a Word or PDF document that incorporates ASCII art. I am referring to the fact that more and more people are reading documents on cell-phones and other small devices. According to analysts, this will be the most popular platform for reading material from the Internet within a few years. But among what audience? End-users at large, yes, I can certainly believe that. But techies, especially of sufficient caliber to even *want* to read the IETF's output, let alone participate in creating it? Very doubtful. I don't think we'll be giving up our laptops, never mind large monitors, any time soon. Phones and tablets are for content *consumption*. We are content *creators*, be it programs, documents, or whatever. That's an entirely different set of hardware requirements. When was the last time you saw a program or document or anything else of significant size, written using a phone, or even a tablet? -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SYzsACgkQ9RoMZyVa61eSRACfQsLQvu0pa/gR/LTNlGiMBpIH /w0AoINZZMQGcPqUzn9QK/nlQR/w/oUq =2eH4 -END PGP SIGNATURE- ___ Ietf mailing list
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SjXcACgkQ9RoMZyVa61ctQwCgp5s/U1a5h/8B1bUM+1iTY6P6 I2UAnRvf4qeSRwwmzBP3XRVX5raLMdcI =XIXx -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 11:20 AM, Marc Petit-Huguenin wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). http://ietf.implementers.org/mime/rfc5928.txt now returns text/lp http://ietf.implementers.org/format/rfc5928.txt now returns text/plain;format=lp - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SjvwACgkQ9RoMZyVa61dwmQCaAhj6WDUNR3Zvv04jSA2Xs65y 2LcAn3vLq1/LOUxyfTCpkHzPKvHfj42f =ba/+ -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
--On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. This (IMO, deficient) issue with browsers refusing to differentiate / dispatch on parameters is the traditional issue with such parameters. The choice then becomes one between fix the obscenity browsers and propagate media subtypes when parameters would do. I obviously have a preference, but it may not be practical/realistic. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. Yep, although that modification would serve us well in lots of other ways, IMO. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. But RFC 3636 says (Section 3) Text/Plain is usually displayed as preformatted text, often in a fixed font.. That is clearly a lot short of a requirement but, if one were going to use a line length parameter, one could specify that it implies a fixed-width font or display system (or name it something that would make that more clear). I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/27/2011 11:38 AM, John C Klensin wrote: --On Sunday, November 27, 2011 11:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: On 11/27/2011 10:36 AM, John C Klensin wrote: --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin petit...@acm.org wrote: The problem here is that RFC and Internet-Drafts are not plain ASCII. They are technically in a special format that I would call line-printer ready text file, and ASCII is the encoding, not the format. What is needed is: - - A mime-type for line-printer ready text (say text/lp) - - An heuristic to recognize text/lp files (it's too late for a specific extension). Apache HTTP server can use the AddType directive for these files[1]. - - A program to display text/lp files, one at least for each platform. If someone take care of the mime-type, I'll write the program to display correctly text/lp files on the Android platform. Out of curiosity (and again my better judgment about getting further involved in this discussion), why do you think text/lp is needed and not text/plain; charset=US-ASCII; format=lp ? Did not think of that, that's better IMO. Apache can do this (the link I gave in a previous email is now returning text/plain; format=lp; charset=us-ascii). But this creates practical issues. My browser is not capable of assigning a specific helper to text/plain; format=lp, say /usr/bin/qrfcview (i.e. different from text/plain; format=fixed which in my case would be assigned to /usr/bin/gvim). An Android app would have the same issue as I guess many other platforms. This (IMO, deficient) issue with browsers refusing to differentiate / dispatch on parameters is the traditional issue with such parameters. The choice then becomes one between fix the obscenity browsers and propagate media subtypes when parameters would do. I obviously have a preference, but it may not be practical/realistic. It is the display application that will have to use this parameter to select the display mode, so instead of having an additional program per platform that displays the text/lp type, we will need to modify all applications that can render text/plain so they can correctly interpret the format=lp parameter. Yep, although that modification would serve us well in lots of other ways, IMO. (please read RFC 3676 before answering -- it is not clear to me that format=fixed would not do as well, possibly supplemented by an additional line length parameter. What would be missing is an indication that only a fixed font must be used. But RFC 3636 says (Section 3) Text/Plain is usually displayed as preformatted text, often in a fixed font.. That is clearly a lot short of a requirement but, if one were going to use a line length parameter, one could specify that it implies a fixed-width font or display system (or name it something that would make that more clear). That would work too. I added a third URL that returns text/plain;format=fixed;line-length=72 http://ietf.implementers.org/fixed/rfc5928.txt I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. john - -- Marc Petit-Huguenin Personal email: m...@petit-huguenin.org Professional email: petit...@acm.org Blog: http://blog.marc.petit-huguenin.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7SlCoACgkQ9RoMZyVa61c4twCgpONWZDAtNdLObMMCbIhJ0tBV CboAoJEqk3z5QuBopwDdCwSTtEgAbpjZ =ZxUz -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]
On 27 November 2011 20:38, John C Klensin john-i...@jck.com wrote: I'm willing to write up either an extension/update to RFC3676 or a new subtype if there is enough expression of interest (not just the two of us) to indicate that such a proposal would be likely to go somewhere. As Gmail web UI user I'm interested in any attempts to get the concept of monospaced to the attention of Google engineers. So far a user script (or of course a MUA such as TB) do the trick for me after Gmail killed its monospaced lab some years ago. Use simple words (4 or less characters) in short sentences (no commas, semicolons, dashes, only MUSTard and periods), this is a very advanced topic for folks who never used command lines or punched cards. -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
