[pld-builder]: kompresowanie logów w mailach; check-files

[Jacek Konieczny]

On Fri, Jul 26, 2002 at 08:23:13PM +0200, Arkadiusz Miskiewicz wrote:
> > On Fri, Jul 26, 2002 at 03:17:32PM +0200, Arkadiusz Miskiewicz wrote:
> > >   Content-Type: text/x-bzip2
> > To jest nieprawidłowy typ pliku!!!!!
> > 
> > Zgodnie z jakimś-tam RFC 
> Znalazłem... 2046
> 
> > Pliki z-bzip2owane tego warunku nie spełniają, więc
> > taki Content-Type jest nieprawidłowy!
> > Prawidłowy Content-Type to: application/x-bzip2
> To teraz skąd MUA mają wiedzieć, że to jest tekst, a nie jakiś tar.bz2?

Po "copiousoutput" w /etc/mailcap?

> Chyba jest jakaś możliwość powiedzenia: to jest txt skompresowane bzip2em?
W MIME dla poczty elektronicznej chyba nie bardzo :-(

> W Debianowym mailcap jest tak:
> 
> #  Note: Compression schemes like "gzip", "bzip", and "compress" are not
> #  actually "mime-types".  They are "encodings" and hence must _not_ have
> #  entries in this file to map their extensions. The "mime-type" of an
> #  encoded file refers to the type of data that has been encoded, not the
> #  type of the encoding.                                 
W sumie racja. Bo jeszcze by mi mutt zaczął rozkompresowane tar.gz
wyświetlać w treści wiadomości :-)
Ale mimo wszystko uważam, że to powinno być w mime-types. Jak ktoś chce
ściąga tar.gz, to znaczy że chce ściągnąć zgzipowanego tara, a nie po
prostu tara. A jakby serwer przedstawił to jako tar zakodowany gzipem,
to po ściągnięciu przeglądarka powinna to rozkodować i zapisać
nieskompresowane. Jakoś niezbyt mi się to podoba.

> czyli coś się to kupy nie trzyma bo z tego wychodzi, że dla txt kompresowanego
> bzip2'em prawidłowy typ to text/plain + encoding = x-bzip2? Z tym, że jeśli
> chodzi o encodingi to jest tylko Content-Transfer-Encoding - x-bzip2? To już
> coraz bardziej dziwniejsze bo przecież żaden MUA nie zrozumie
>  Content-Transfer-Encoding: x-bzip2 choć rfc mówi ok.
W protokole HTTP jest np. Content-Encoding. I tam jest sytuacja jasna.
Ale w specyfikacji MIME czegoś takiego nie widzę. 

> rfc2912 znów wyskakuje z Content-features czyli coś w stylu:
>  Content-type: application/x-bzip2
>  Content-features: (& (Type="text/plain") (charset=US-ASCII) )
>  Content-transfer-encoding: base64          
Hmmm. Tego nie znałem. Rozumie to np. mutt?

> Jakieś pomysły?
Napewno nie text/x-bzip. 

> > Trzymajmy się lepiej standardów, bo nie wiele PLD będzie się od Windows
> > różnić.
> Ano trzymajmy się.
Ale jak widać, to nie takie proste :-)

Pozdrowienia,
        Jacek