ietf
[Top] [All Lists]

Re: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]

2011-11-27 13:49:14
-----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

<Prev in Thread] Current Thread [Next in Thread>