yEnc support in Gnus?

yEnc support in Gnus?

[Ted Zlatanov]

Has anyone heard of yEnc?

http://www.yenc.org/yenc/index.htm

Seems to be supported by Forte and a few other news readers.
Basically a straight binary transliteration, with a few escaped
characters.  It has a very low overhead compared to BASE64 and such,
and assumes that news servers can handle most binary characters.

yEnc has some rudimentary checksums as well.

Ted

Re: yEnc support in Gnus?

[Matthias Andree]

On Thu, 27 Jun 2002, Ted Zlatanov wrote:

> Has anyone heard of yEnc?
> 
> http://www.yenc.org/yenc/index.htm

Please refrain from adding yEnc to Gnus. yEnc is junk, it has a bad
implementation, is not MIME-aware and does not solve any problem without
giving rise to new problems. base64 is well-proven and robust. yEnc is
not.

Re: yEnc support in Gnus?

[Simon Josefsson]

Ted Zlatanov <teodor.zlatanov@divine.com> writes:

> Has anyone heard of yEnc?
>
> http://www.yenc.org/yenc/index.htm
>
> Seems to be supported by Forte and a few other news readers.
> Basically a straight binary transliteration, with a few escaped
> characters.  It has a very low overhead compared to BASE64 and such,
> and assumes that news servers can handle most binary characters.

When someone writes a MIME CTE definition of the encoding, I'll offer
a patch for it.  I guess decoding support for the current format could
be added to Gnus if someone sends a patch, but supporting encoding is
a bad idea IMHO.

Re: yEnc support in Gnus?

[Stainless Steel Rat]

* Simon Josefsson <jas@extundo.com>  on Thu, 27 Jun 2002
| When someone writes a MIME CTE definition of the encoding, I'll offer
| a patch for it.  I guess decoding support for the current format could
| be added to Gnus if someone sends a patch, but supporting encoding is
| a bad idea IMHO.

As it currently stands, yEnc's b0rken implementation leaves Gnus with only
one sane way of implementing encoding: hijacking (or duplicating)
uudecode's functionality and dumping stuff through an external yDec
processor.  And even that might not work right.  yEnc's total disregard of
defacto and published standards is a right pain in the behind.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball contains a liquid core,
Minion of Nathan - Nathan says Hi! \ which, if exposed due to rupture, should
PGP Key: at a key server near you!  \ not be touched, inhaled, or looked at.
       That and five bucks will get you a small coffee at Starbucks.

Re: yEnc support in Gnus?

[Ted Zlatanov]

On Thu, 27 Jun 2002, ratinox@peorth.gweep.net wrote:
> * Simon Josefsson <jas@extundo.com>  on Thu, 27 Jun 2002
>| When someone writes a MIME CTE definition of the encoding, I'll
>| offer a patch for it.  I guess decoding support for the current
>| format could be added to Gnus if someone sends a patch, but
>| supporting encoding is a bad idea IMHO.
> 
> As it currently stands, yEnc's b0rken implementation leaves Gnus
> with only one sane way of implementing encoding: hijacking (or
> duplicating) uudecode's functionality and dumping stuff through an
> external yDec processor.  And even that might not work right.
> yEnc's total disregard of defacto and published standards is a right
> pain in the behind.

Good to know, thanks.  I had not seen discussion of yEnc on this list,
that's why I brought it up.  I'll use the external decoder if I have
to.

Thanks
Ted

Re: yEnc support in Gnus?

[Per Abrahamsen]

Matthias Andree <matthias.andree@gmx.de> writes:

> Please refrain from adding yEnc to Gnus. yEnc is junk, it has a bad
> implementation, is not MIME-aware and does not solve any problem without
> giving rise to new problems. base64 is well-proven and robust. yEnc is
> not.

I agree with everything above, except the first sentence.  yEnc is
quickly becoming a de facto standard for binaries on parts of the net,
and Gnus ought to provide at least decoding support, no matter how
much it suck.  Of course, provided someone actually volunteer to
implement it.

Also, to yEncs defence, while a lot of us had clever ideas of how to
provide more optimized mechanisms for transport of binaries over 8bit
lines, the yEnc creator actually went ahead and implemented a
solution.  Somehow it warms my heart to see that the net is still be
shaped by an individual who actually go ahead and program something,
despite the discouragement from all us old talking heads.  Kind of
like when Bill Joy got tired of waiting for the official telnet and
ftp protocols, and went ahead and implemented rsh and rcp.

Re: yEnc support in Gnus?

[Matthias Andree]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Matthias Andree <matthias.andree@gmx.de> writes:
>
>> Please refrain from adding yEnc to Gnus. yEnc is junk, it has a bad
>> implementation, is not MIME-aware and does not solve any problem without
>> giving rise to new problems. base64 is well-proven and robust. yEnc is
>> not.
>
> I agree with everything above, except the first sentence.  yEnc is
> quickly becoming a de facto standard for binaries on parts of the net,
> and Gnus ought to provide at least decoding support, no matter how
> much it suck.  Of course, provided someone actually volunteer to
> implement it.

It serves not other purpose than abusing Usenet structures and NNTP for
distribution of 0dayz-warez, what it was never designed for.

What good is this stuff in Gnus? Not at all. There are hundreds of tools
which are a dozen times more efficient than Emacs at decoding binary
stuff. Check freshmeat.

> Also, to yEncs defence, while a lot of us had clever ideas of how to
> provide more optimized mechanisms for transport of binaries over 8bit
> lines, the yEnc creator actually went ahead and implemented a
> solution.

Yes. It's a step back in terms of transmission reliability.

Helbing has been told in news:de.comm.software.newsserver to make yEnc
MIME-aware a dozen times, but never got around to do it. Presumably, he
does not understand MIME; but he didn't come up with real questions
either.

There's a reason that there are only binary, quoted-printable and base64
encoding: these are the reliable ones.

Why proliferate encodings when there are better protocols that can send
binary data unencoded? HTTP, FTP, GNUTELLA, and more exist with a vast
choice of software for each protocol. Use these for binary distribution.

-- 
Matthias Andree

Re: yEnc support in Gnus?

[Matthias Andree]

Ted Zlatanov <teodor.zlatanov@divine.com> writes:

> Good to know, thanks.  I had not seen discussion of yEnc on this list,
> that's why I brought it up.  I'll use the external decoder if I have
> to.

It will be more efficient anyways.

BTW, good to know (from your Organization:-Header) that my Cyrillic
display works, although I can hardly read it and know no language that
uses Cyrillic letters. :-)

-- 
Matthias Andree

Re: yEnc support in Gnus?

[Per Abrahamsen]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> It serves not other purpose than abusing Usenet structures and NNTP for
> distribution of 0dayz-warez, what it was never designed for.

I have no idea what 0dayz-warez is, sorry, I don't speak 1331.

As far as I can see, it serve the same purpose as uuencode, except
over 8bit rather than 7bit lines.

> What good is this stuff in Gnus? Not at all. There are hundreds of tools
> which are a dozen times more efficient than Emacs at decoding binary
> stuff. Check freshmeat.

Sure if I was a serious downloader, but I'm happy to use Gnus for the
occasional relevant binary I see.  I do not see any reason other than
nobody has implemented it yet, I shouldn't be able to do the same when
it is yEnc instead of uuencode.

> Yes. It's a step back in terms of transmission reliability.

And a step forward in efficiency.  A tradeoff many people like,
otherwise it would not be used.

> Helbing has been told in news:de.comm.software.newsserver to make yEnc
> MIME-aware a dozen times, but never got around to do it. 

Right.  We are a lot of clever people who like to sit on our flat
*sses and tell others what to do.  But the power is with the doers,
not the talkers.

> Presumably, he does not understand MIME; but he didn't come up with
> real questions either.

He has said as much. 

> There's a reason that there are only binary, quoted-printable and base64
> encoding: these are the reliable ones.

There is also 8bit.  yEnc demonstrates that there is a market for an
binary over 8bit transfer encoding.  yEnc is technically a poor
solution for that problem.  The two honorable things to do about that
is a) help implement a better 8bit-over-binary solution, and b) shut
up.

> Why proliferate encodings when there are better protocols that can send
> binary data unencoded?

Better is subjective, it is clearly not better for the people who use
NNTP, or they would use the alternatives instead.  

> HTTP, FTP, GNUTELLA, and more exist with a vast choice of software
> for each protocol. Use these for binary distribution.

HTTP and FTP are not broadcast, so they don't compare on a technical
level with NNTP.  I have no idea of what kind of protocol gnutella is.

And I think the whole "you must not distribute binaries over NNTP"
religion is stupid.  NNTP and Usenet has been used for binaries for as
long as I have been there (15 years, in "comp.binaries"), I doubt some
new-age techno-moral arguments that have become in vogue recently are
going to change that.  People will stop using NNTP for binaries when
people stop using NNTP for binaries.  Let's deal with the real world
here.

BTW: Gnus 5 started life as an add-on module to Gnus 4 for decoding
uuencoded postings. 

Re: yEnc support in Gnus?

[Ted Zlatanov]

On Sun, 30 Jun 2002, abraham@dina.kvl.dk wrote:
>> HTTP, FTP, GNUTELLA, and more exist with a vast choice of software
>> for each protocol. Use these for binary distribution.
> 
> HTTP and FTP are not broadcast, so they don't compare on a technical
> level with NNTP.  I have no idea of what kind of protocol gnutella
> is.

Gnutella Net (I don't know the official name) is a network protocol to
build a distributed network of machines, and search for content.  The
actual file transfers are done with HTTP, I believe.  See
http://www.gnutelladev.com/ for more information on the protocol.

Ted

Re: yEnc support in Gnus?

[Simon Josefsson]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>> There's a reason that there are only binary, quoted-printable and base64
>> encoding: these are the reliable ones.
>
> There is also 8bit.  yEnc demonstrates that there is a market for an
> binary over 8bit transfer encoding.  yEnc is technically a poor
> solution for that problem.  The two honorable things to do about that
> is a) help implement a better 8bit-over-binary solution, and b) shut
> up.

That's a hint if I ever saw one. :-)

So, what would be required to implement a better solution?  What does
yEnc provide that the existing MIME binary CTE and the Content-MD5
techniques doesn't already?  Escaping of CR/LF/NUL?  Content-MD5
doesn't work with message/partial though, but I remember seeing a I-D
defining Content-Hash, or something similar, for HTTP that fixes that.

Perhaps we could ask the people that has anti-yEnc web sites if they
want to help define a better scheme (some of the web sites provide
suggested MIME aware alternatives, altough not in I-D format).

Re: yEnc support in Gnus?

[Florian Weimer]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> It serves not other purpose than abusing Usenet structures and NNTP for
> distribution of 0dayz-warez, what it was never designed for.

Ironically, all other efforts to create a similar publishing
instrument have failed in some way or the other.

(Although binary Usenet distribution took a serios hit in Europe
because one satellite feed provider (the only one?) close down.)

Re: yEnc support in Gnus?

[Florian Weimer]

Ted Zlatanov <teodor.zlatanov@divine.com> writes:

>> HTTP and FTP are not broadcast, so they don't compare on a technical
>> level with NNTP.  I have no idea of what kind of protocol gnutella
>> is.
>
> Gnutella Net (I don't know the official name) is a network protocol to
> build a distributed network of machines, and search for content.  The
> actual file transfers are done with HTTP, I believe.  See
> http://www.gnutelladev.com/ for more information on the protocol.

NNTP is in fact less bandwidth intense than Gnutella. ;-)

Re: yEnc support in Gnus?

[Russ Allbery]

Simon Josefsson <jas@extundo.com> writes:

> So, what would be required to implement a better solution?  What does
> yEnc provide that the existing MIME binary CTE and the Content-MD5
> techniques doesn't already?  Escaping of CR/LF/NUL?

Right.

> Content-MD5 doesn't work with message/partial though, but I remember
> seeing a I-D defining Content-Hash, or something similar, for HTTP that
> fixes that.

> Perhaps we could ask the people that has anti-yEnc web sites if they
> want to help define a better scheme (some of the web sites provide
> suggested MIME aware alternatives, altough not in I-D format).

<http://www.exit109.com/~jeremy/news/yenc.html> is a good start.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: yEnc support in Gnus?

[Steinar Bang]

>>>>> Russ Allbery <rra@stanford.edu>:

> Simon Josefsson <jas@extundo.com> writes:

>> So, what would be required to implement a better solution?  What does
>> yEnc provide that the existing MIME binary CTE and the Content-MD5
>> techniques doesn't already?  Escaping of CR/LF/NUL?

> Right.

It may be a good idea for interoperability, to insert the odd CR/LF
at, say, 510 char intervals?

Re: yEnc support in Gnus?

[Matthias Andree]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Right.  We are a lot of clever people who like to sit on our flat
> *sses and tell others what to do.  But the power is with the doers,
> not the talkers.

But why should I implement code for a badly-crafted and badly-documented
protocol like yEnc if I'm satisfied with base64 for the occasional
binary?

>> Why proliferate encodings when there are better protocols that can send
>> binary data unencoded?
>
> Better is subjective, it is clearly not better for the people who use
> NNTP, or they would use the alternatives instead.

NNTP is doing broadcast distribution over unicast media. That must fail
some day.

-- 
Matthias Andree

Re: yEnc support in Gnus?

[Kai Großjohann]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> NNTP is doing broadcast distribution over unicast media. That must fail
> some day.

It hasn't failed yet.  It is quite old.  That means NNTP can be
considered a success already, even if it fails tomorrow.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: yEnc support in Gnus?

[Stainless Steel Rat]

* Matthias Andree <ma@dt.e-technik.uni-dortmund.de>  on Tue, 02 Jul 2002
| NNTP is doing broadcast distribution over unicast media. That must fail
| some day.

Broadcast as far as networking protocols are concerned usually means
packets sent to every host on a segment.  Broadcast packets are usually not
routeable.  NNTP is not broadcast.

You may be thinking of multicast, which is similar to broadcast in that it
sends packets to many machines, but it is different in that multicast
packets are routeable and multicast packets are not sent to every machine.
NNTP is not multicast, either.

So, what is it that you are trying to say?

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: yEnc support in Gnus?

[Russ Allbery]

Steinar Bang <sb@dod.no> writes:
>>>>>> Russ Allbery <rra@stanford.edu>:
>> Simon Josefsson <jas@extundo.com> writes:

>>> So, what would be required to implement a better solution?  What does
>>> yEnc provide that the existing MIME binary CTE and the Content-MD5
>>> techniques doesn't already?  Escaping of CR/LF/NUL?

>> Right.

> It may be a good idea for interoperability, to insert the odd CR/LF
> at, say, 510 char intervals?

Right.  yEnc, IIRC, does that.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: yEnc support in Gnus?

[Matthias Andree]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> Broadcast as far as networking protocols are concerned usually means
> packets sent to every host on a segment.  Broadcast packets are usually not
> routeable.  NNTP is not broadcast.
>
> You may be thinking of multicast, which is similar to broadcast in that it
> sends packets to many machines, but it is different in that multicast
> packets are routeable and multicast packets are not sent to every machine.
> NNTP is not multicast, either.
>
> So, what is it that you are trying to say?

"Broadcast" is not to be seen in the strict and network-layer oriented
sense. NNTP is being (ab)used for binary distribution, it carries data
regardless of whether this data has been requested or not. Call it
broadcast or multicast, doesn't matter, the traffic is there even if
no-one is listening. That's quite different from a request -> serve
structure with distributed caches (HTTP can do that, with squid e. g).

-- 
Matthias Andree

Re: yEnc support in Gnus?

[Stainless Steel Rat]

* Matthias Andree <ma@dt.e-technik.uni-dortmund.de>  on Wed, 03 Jul 2002
| "Broadcast" is not to be seen in the strict and network-layer oriented
| sense. NNTP is being (ab)used for binary distribution, it carries data
| regardless of whether this data has been requested or not.

Not true.  Every news server requests the contents of a list of newsgroups
from its upstream server(s).  For example, back when I was a news admin, my
site wanted all binaries groups except the pictures groups.  We wanted to
avoid possible copyright problems with the picture groups.  My newsfeeds
file had "alt.*" and "!alt.binaries.pictures.*", requests to the upstream
servers to send us everything in alt, including the binaries groups, but
excluding the pictures groups.

By default, a feed in a newsfeeds file requests no news at all.  The news
server admin must fill in a list of groups that his server will carry, even
if that list is simply "*".  Additionally, the news server admin must
manually perform newgroup commands, or configure his server to automaticaly
perform them or ignore them entirely.

You may want to argue implicit vs. explicit, but there is no such thing as
unrequested news.

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: yEnc support in Gnus?

[Steinar Bang]

>>>>> Stainless Steel Rat <ratinox@peorth.gweep.net>:

> You may want to argue implicit vs. explicit, but there is no such
> thing as unrequested news.

Yes there is.  It's called "spam".

Re: yEnc support in Gnus?

[Matthias Andree]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> You may want to argue implicit vs. explicit, but there is no such thing as
> unrequested news.

You're missing the point. Of course, the whole bunch is solicited, but
you don't get to choose individual articles or files (but you do with
HTTP/FTP).

-- 
Matthias Andree

Re: yEnc support in Gnus?

[Per Abrahamsen]

Matthias Andree <ma@dt.e-technik.uni-dortmund.de> writes:

> You're missing the point. Of course, the whole bunch is solicited, but
> you don't get to choose individual articles or files (but you do with
> HTTP/FTP).

And this is significant because?

I believe it should be up to the server administrators to decide, for
whatever reasons they might have.

For example, using a client/server protocol like HTTP or FTP for very
popular files like pr0n and warez would be stupid from a technical
point of view, when a flooding protocol like Usenet is way more
efficient for that kind of stuff.  On the other hand, using Usenet for
technical discussions is hopelessly inefficient, the interest is low
enough that a peer to peer or client/server protocol in most cases
would be more efficient. 

Of course, mirrors and caching muddles this somewhat, as it makes HTTP
and FTP look more like a primitive flooding protocol.  And NNTP can
easily be used in a pure client/server setup, just avoid giving or
accepting feeds.

However, technical issues alone aren't (and shouldn't be) the deciding
factor.  Many ISP's feel that offering local access to textual
discussions on Usenet is a worthwhile added value.  And some don't
feel the same way about popular groups for binaries, even if it makes
more sense from a technical perspective.  Other factors such as user
expectations, available software, and habbits also play a role on what
parts of Usenet to offer.

Re: yEnc support in Gnus?

[Stainless Steel Rat]

* Steinar Bang <sb@dod.no>  on Thu, 04 Jul 2002
| Yes there is.  It's called "spam".

Usenet spam isn't news.
Next!

:)

-- 
Rat <ratinox@peorth.gweep.net>    \ If Happy Fun Ball begins to smoke, get
Minion of Nathan - Nathan says Hi! \ away immediately. Seek shelter and cover
PGP Key: at a key server near you!  \ head.
       That and five bucks will get you a small coffee at Starbucks.

Re: yEnc support in Gnus?

[Stainless Steel Rat]

* Matthias Andree <ma@dt.e-technik.uni-dortmund.de>  on Thu, 04 Jul 2002
| You're missing the point. Of course, the whole bunch is solicited, but
| you don't get to choose individual articles or files (but you do with
| HTTP/FTP).

When you buy a news paper or magazine, you get the whole thing in a single
lump.  You do not get to choose individual articles or columns.  If there
are articles you do not want to read, well, you suck it up.  Or maybe give
it to a friend when you are done reading it.  Usenet news is patterened
after that idea.  A news server is like a humongous news paper shared by
many users.

Actually, nntpcache -does- let the users choose individual articles without
having to download entire groups or heirarchies.

-- 
Rat <ratinox@peorth.gweep.net>    \ Happy Fun Ball may stick to certain types
Minion of Nathan - Nathan says Hi! \ of skin.
PGP Key: at a key server near you!  \ 
       That and five bucks will get you a small coffee at Starbucks.

Re: yEnc support in Gnus?

[Gerd Flaig]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> NNTP is not multicast, either.

true, but you might want to take a look at

   http://mcntp.sourceforge.net/

Mcntp is a (Usenet-)news transport protocol and its
implementation. The difference between mcntp and nntp is that with
mcntp, articles are transferred over IP-multicast (which uses UDP) and
not via TCP. Thus articles that are sent by one sender once can be
received by multiple receivers.

       Goodbyte, Gerd.
-- 
Gerd Flaig                     Technik                gerd@schlund.de
Bei Schlund + Partner AG       Erbprinzenstr. 4-12  D-76133 Karlsruhe
 Physics is like sex: sure, it may give some practical results,
 but that's not why we do it. -- Richard Feynman

Re: yEnc support in Gnus?

[Jesper Harder]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Simon Josefsson <jas@extundo.com> writes:

> Ted Zlatanov <teodor.zlatanov@divine.com> writes:
>
>> Has anyone heard of yEnc?
>>
>> Seems to be supported by Forte and a few other news readers.
>> Basically a straight binary transliteration, with a few escaped
>> characters.
>
> When someone writes a MIME CTE definition of the encoding, I'll offer
> a patch for it.  I guess decoding support for the current format could
> be added to Gnus if someone sends a patch, 

Here's a patch.  It has some limitations -- it doesn't:

* handle multipart binaries, 
* check the crc32 checksum (it didn't seem very straight-forward, when
  you've only got 28 bit ints), 
* support an external decoder (the elisp decoder wasn't too slow, so I
  didn't bother)

> but supporting encoding is a bad idea IMHO.

I agree.


2002-08-07  Jesper harder  <harder@ifa.au.dk>

	* yenc.el: New file.

	* mm-uu.el (mm-uu-yenc-decode-function): New variable.
	(mm-uu-type-alist): Add yenc.
	(mm-uu-yenc-filename): New function.
	(mm-uu-yenc-extract): New function.

	* mm-bodies.el (mm-decode-content-transfer-encoding): Add yenc.

2002-08-07  Jesper harder  <harder@ifa.au.dk>

	* emacs-mime.texi (Non-MIME): Add yenc.
	(yenc): New node.



[-- Attachment #2: yenc.el --]
[-- Type: application/emacs-lisp, Size: 4514 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: mm-bodies.el.diff --]
[-- Type: text/x-patch, Size: 759 bytes --]

--- /home/harder/gnus/lisp/mm-bodies.el	Sat Nov 24 19:36:22 2001
+++ mm-bodies.el	Tue Jul 23 23:25:27 2002
@@ -223,6 +223,10 @@
 	    (require 'mm-uu)
 	    (funcall mm-uu-binhex-decode-function (point-min) (point-max))
 	    t)
+	   ((eq encoding 'x-yenc)
+	    (require 'mm-uu)
+	    (funcall mm-uu-yenc-decode-function (point-min) (point-max))
+	    )
 	   ((functionp encoding)
 	    (funcall encoding (point-min) (point-max))
 	    t)
@@ -232,7 +236,7 @@
 	 (message "Error while decoding: %s" error)
 	 nil))
     (when (and
-	   (memq encoding '(base64 x-uuencode x-uue x-binhex))
+	   (memq encoding '(base64 x-uuencode x-uue x-binhex x-yenc))
 	   (equal type "text/plain"))
       (goto-char (point-min))
       (while (search-forward "\r\n" nil t)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: mm-uu.el.diff --]
[-- Type: text/x-patch, Size: 1932 bytes --]

--- /home/harder/gnus/lisp/mm-uu.el	Wed Jan 30 14:59:30 2002
+++ mm-uu.el	Wed Jul 24 01:48:53 2002
@@ -40,6 +40,9 @@
 (autoload 'binhex-decode-region-external "binhex")
 (autoload 'binhex-decode-region-internal "binhex")
 
+(autoload 'yenc-decode-region "yenc")
+(autoload 'yenc-extract-filename "yenc")
+
 (defcustom mm-uu-decode-function 'uudecode-decode-region
   "*Function to uudecode.
 Internal function is done in Lisp by default, therefore decoding may
@@ -61,6 +64,8 @@
 		 (function-item :tag "External" binhex-decode-region-external))
   :group 'gnus-article-mime)
 
+(defvar mm-uu-yenc-decode-function 'yenc-decode-region)
+
 (defvar mm-uu-pgp-beginning-signature
      "^-----BEGIN PGP SIGNATURE-----")
 
@@ -90,6 +95,11 @@
      mm-uu-binhex-extract
      nil
      mm-uu-binhex-filename)
+    (yenc
+     "^=ybegin.*size=[0-9]+.*name=.*$"
+     "^=yend.*size=[0-9]+"
+     mm-uu-yenc-extract
+     mm-uu-yenc-filename)
     (shar
      "^#! */bin/sh"
      "^exit 0$"
@@ -205,6 +215,12 @@
 	(ignore-errors
 	  (binhex-decode-region start-point end-point t))))
 
+(defun mm-uu-yenc-filename ()
+  (goto-char start-point)
+  (setq file-name
+	(ignore-errors
+	  (yenc-extract-filename))))
+
 (defun mm-uu-forward-test ()
   (save-excursion
     (goto-char start-point)
@@ -262,6 +278,19 @@
 		      (list mm-dissect-disposition
 			    (cons 'filename file-name)))))
 
+(defun mm-uu-yenc-extract ()
+  (mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
+		  (list (or (and file-name
+				 (string-match "\\.[^\\.]+$" file-name)
+				 (mailcap-extension-to-mime
+				  (match-string 0 file-name)))
+			    "application/octet-stream"))
+		  'x-yenc nil
+		  (if (and file-name (not (equal file-name "")))
+		      (list mm-dissect-disposition
+			    (cons 'filename file-name)))))
+
+
 (defun mm-uu-shar-extract ()
   (mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
 		  '("application/x-shar")))

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: emacs-mime.texi.diff --]
[-- Type: text/x-patch, Size: 1345 bytes --]

--- /home/harder/gnus/texi/emacs-mime.texi	Sat May  4 16:22:50 2002
+++ emacs-mime.texi	Wed Jul 24 05:19:29 2002
@@ -132,8 +132,8 @@
 @section Non-MIME
 
 Gnus also understands some non-@sc{mime} attachments, such as
-postscript, uuencode, binhex, shar, forward, gnatsweb, pgp.  Each of
-these features can be disabled by add an item into
+postscript, uuencode, binhex, yenc, shar, forward, gnatsweb, pgp.
+Each of these features can be disabled by add an item into
 @code{mm-uu-configure-list}.  For example,
 
 @lisp
@@ -154,6 +154,10 @@
 @findex binhex
 Binhex encoded file.
 
+@item yenc
+@findex yenc
+Yenc encoded file.
+
 @item shar
 @findex shar
 Shar archive file.
@@ -1041,6 +1045,7 @@
 * base64::       Base64 en/decoding.
 * binhex::       Binhex decoding.
 * uudecode::     Uuencode decoding.
+* yenc::         Yenc decoding.
 * rfc1843::      Decoding HZ-encoded text.
 * mailcap::      How parts are displayed is specified by the @file{.mailcap} file
 @end menu
@@ -1482,6 +1487,21 @@
 @end table
 
 
+@node yenc
+@section yenc
+@cindex yenc
+
+@code{yenc} is used for encoding binaries on Usenet.  The following
+function is supplied by this package:
+
+@table @code
+@item yenc-decode-region
+@findex yenc-decode-region
+Decode the encoded text in the region.
+
+@end table
+
+
 @node rfc1843
 @section rfc1843
 @cindex rfc1843

Re: yEnc support in Gnus?

[Per Abrahamsen]

Jesper Harder <harder@ifa.au.dk> writes:

> * check the crc32 checksum (it didn't seem very straight-forward, when
>   you've only got 28 bit ints), 

Maybe you can do it with floats?  

Re: yEnc support in Gnus?

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 705 bytes --]

Jesper Harder <harder@ifa.au.dk> writes:

> Here's a patch.

Great, thanks!  Added.  I guess you have signed papers?

> It has some limitations -- it doesn't:
>
> * handle multipart binaries, 
> * check the crc32 checksum (it didn't seem very straight-forward, when
>   you've only got 28 bit ints), 
> * support an external decoder (the elisp decoder wasn't too slow, so I
>   didn't bother)

I expect that committing this will make these limitations magicly
vanish over time.  Perhaps you can find out if the attached crc32.el
will work.  I guess the main problem is getting it assigned to FSF.

>> but supporting encoding is a bad idea IMHO.
>
> I agree.

Except a better, MIME-aware, version of yEnc.

[-- Attachment #2: crc32.el --]
[-- Type: application/emacs-lisp, Size: 7543 bytes --]

Re: yEnc support in Gnus?

[Jesper Harder]

Simon Josefsson <jas@extundo.com> writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> Here's a patch.
>
> Great, thanks!  Added.  I guess you have signed papers?

Yup.

> Perhaps you can find out if the attached crc32.el will work.  I guess
> the main problem is getting it assigned to FSF.

It doesn't seem to work -- it returns a different result than the other
crc32 routines I tried.

-- 
I mean, if 10 years from now, when you are doing something quick and
dirty, you suddenly visualize that I am looking over your shoulder and
say to yourself, »Dijkstra would not have liked this«, well, that
would be enough immortality for me. -- E.W. Dijkstra

Re: yEnc support in Gnus?

[Matthias Andree]

Simon Josefsson <jas@extundo.com> writes:

> Except a better, MIME-aware, version of yEnc.

That won't happen as long as the clueful are cheerful and content with
just base64, unless someone sells Jürgen Helbing a clue (which he is
immune to.)

-- 
Matthias Andree