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