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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]