-----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(_at_)acm(_dot_)org> wrote:
On 11/27/2011 10:36 AM, John C Klensin wrote:
--On Sunday, November 27, 2011 08:20 -0800 Marc Petit-Huguenin
<petithug(_at_)acm(_dot_)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: marc(_at_)petit-huguenin(_dot_)org
Professional email: petithug(_at_)acm(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf