-----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 > <petithug@xxxxxxx> wrote: > > >> On 11/27/2011 10:36 AM, John C Klensin wrote: >>> >>> >>> --On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin >>> <petithug@xxxxxxx> 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: marc@xxxxxxxxxxxxxxxxxx Professional email: petithug@xxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf