>Sure, but reading this list for several years I have the impression,
>that more effort goes into finding consensus than on writing code.
I guess that's a fair criticism, but I think that's unavoidable with
a software project in this situation.
Remember that the ORIGINAL MH was developed in 1979.
Peter Maydell wrote:
> Has there been much of interest gone in since 1.3 to merit a 1.4?
If not, we could still release a 1.3.1. I'm a fan of the release early,
release often principle.
> I did the 'turn handle, release nmh' work last time round but I'm
> currently horribly busy so am unlikely to
Ken Hornstein wrote:
>>That's what (as I understand it) Jon's patch handles (I still use the
>>latest released version of nmh, which predates all this stuff ... there
>>hasn't been a new release (since 1.3) for a long time now...) and makes a
>>standards conforming message.
>
>You know, this has be
> >Well, I always considered the current behaviour a bug, but I didn't say
> >anything, because the nmh-way of software development seemed pretty
> >inefficient and I didn't want to look at the code myself either.
>
> We have a "way" of software development? When did that happen? :-)
>
> In all
> Even for attachments, as I understand it, that's keyed off a pseudo-header
> added to the components file (and so appears in the draft), right? Do we
> really need a switch to enable that. I'm (again) all for backwards
> compatability, but is there any serious believe that people are really
>
>That's what (as I understand it) Jon's patch handles (I still use the
>latest released version of nmh, which predates all this stuff ... there
>hasn't been a new release (since 1.3) for a long time now...) and makes a
>standards conforming message.
You know, this has been bugging me. Should we c
Peter Maydell wrote:
> Ralph Corderoy wrote:
> > I agree. I've never used -attach, instead sticking with
> > #-directives, and yet still send UTF-8 bodies with £ in text/plain
> > emails with no attachments by mistake. This bug doesn't depend on
> > using -attach.
>
> Yes. Perhaps we should make
Ralph Corderoy wrote:
>Peter Maydell wrote:
>> (In fact I think we should go ahead and change the behaviour for
>> not-plain-ASCII bodies even if the user didn't pass the -attach
>> switch, but I'm guessing I might get argued down on that.)
>
>I agree. I've never used -attach, instead sticking wit
Peter Maydell wrote:
> (In fact I think we should go ahead and change the behaviour for
> not-plain-ASCII bodies even if the user didn't pass the -attach
> switch, but I'm guessing I might get argued down on that.)
I agree. I've never used -attach, instead sticking with #-directives,
and yet stil
In this discussion people (other than perhaps Jon, though he hasn't
said this explicitly) have just been assuming that if the e-mail body
of a message contains data that is not ascii, then it must be some other
character set, because after all, all e-mail is text ...
In the days of MIME, that's si
>> The current behavior was the best idea that I had
>> at the time and nobody has said anything about it until recently. I don't
>> mind it changing, but I don't want to all of a sudden get complaints from
>> people who were counting on this behavior.
>
>Well, I always considered the current beha
On Tue, 07 Dec 2010 12:03:38 CST, Earl Hood said:
> On Tue, Dec 7, 2010 at 11:10 AM, Jon Steinhart wrote:
> > I understand that my attachment system does not handle non-ASCII message
> > bodies, but again, that's because non-ASCII message bodies are not "legal".
>
> Please cite an RFC that says n
Jon Steinhart :
> The current behavior was the best idea that I had
> at the time and nobody has said anything about it until recently. I don't
> mind it changing, but I don't want to all of a sudden get complaints from
> people who were counting on this behavior.
Well, I always considered the cu
markus schnalke wrote:
>[2010-12-07 12:33] Jon Steinhart
>Examples for what gets generated from mail *body text*:
Thanks for doing this and saving me the effort ;-)
>The old code generates ...
>
>... for ASCII:
>
> Content-Type: text/plain; name="sendKi9x7j"; x-unix-mode="0644";
> char
Jon, sorry for the harsh mail. I really had been in rage. :-/
In a recent mail, you said:
> The current behavior was the best idea that I had
> at the time and nobody has said anything about it until recently.
I really don't blame you for what we have; quite the opposite: I am
very gretaful for
[2010-12-07 12:33] Jon Steinhart
> Still trying to understand this. Decided to finally look at the code instead
> of
> relying on my fading memory.
:-) Thanks.
> The existing code takes a non-ASCII message body and sends it as an attachment
> of type application/octet-stream.
>
> Your patch
chad wrote:
>On Dec 7, 2010, at 12:48 PM, Ken Hornstein wrote:
>> You know I'm all for backwards compatibility and everything, but
>> I'm wondering ... did the previous behavior actually make sense? Can
>> people argue that it was desirable or correct? Or was the previous
>> behavior actuall
On Dec 7, 2010, at 12:48 PM, Ken Hornstein wrote:
> You know I'm all for backwards compatibility and everything, but
> I'm wondering ... did the previous behavior actually make sense? Can
> people argue that it was desirable or correct? Or was the previous
> behavior actually wrong, and th
> >The existing code takes a non-ASCII message body and sends it as an
> >attachment
> >of type application/octet-stream.
> >
> >Your patch changes this behavior so that it is sent as type text/plain with
> >the
> >appropriately chosen character set.
>
> You know I'm all for backwards compa
>The existing code takes a non-ASCII message body and sends it as an attachment
>of type application/octet-stream.
>
>Your patch changes this behavior so that it is sent as type text/plain with the
>appropriately chosen character set.
You know I'm all for backwards compatibility and everythin
Still trying to understand this. Decided to finally look at the code instead of
relying on my fading memory. Sorry if some of my earlier memory-based comments
were off-base. Please let me know if my understanding of your proposed patch is
correct.
The existing code takes a non-ASCII message bod
Hi,
markus schnalke wrote:
> > BTW, I would suggest using isascii() rather than (*p > 127 || *p < 0).
>
> I just kept what you once wrote. ;-P
> But, yes, you are right.
Given it's `char *p' then *p may be unsigned on some systems, e.g. ARM,
and a compiler could warn on testing if it's negative
On Tue, Dec 7, 2010 at 11:10 AM, Jon Steinhart wrote:
> I understand that my attachment system does not handle non-ASCII message
> bodies, but again, that's because non-ASCII message bodies are not "legal".
Please cite an RFC that says non-ASCII bodies are not legal.
With MIME, you have the Cont
[2010-12-07 09:10] Jon Steinhart
> > [2010-12-07 08:27] Jon Steinhart
> > > Sounds good. Is the patch that you sent out complete? I don't see an
> > > option
> > > that enables/disables this behavior and I think that there should be one.
> >
> > I believe it's correct that there is no switch.
> [2010-12-07 08:27] Jon Steinhart
> > Sounds good. Is the patch that you sent out complete? I don't see an
> > option
> > that enables/disables this behavior and I think that there should be one.
>
> I believe it's correct that there is no switch.
>
> If one wants to deactivate it, do not sp
[2010-12-07 08:27] Jon Steinhart
> Sounds good. Is the patch that you sent out complete? I don't see an option
> that enables/disables this behavior and I think that there should be one.
I believe it's correct that there is no switch.
If one wants to deactivate it, do not specify -attach.
If
Sounds good. Is the patch that you sent out complete? I don't see an option
that enables/disables this behavior and I think that there should be one.
Jon
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-
Hoi,
discussing these things hadn't been easy sometimes, but the points and
arguments became clear and now we reached some kind of consensus. For
me, the discussion had been worthwhile.
[2010-12-03 11:33] Jon Steinhart
>
> o Nobody objects to markus addressing this issue. The objections are
Jon Steinhart wrote:
>Let me try to summarize here because there seems to be lots of energy here
>for commentary but little for things that move us forward:
>
> o Many people still exclusively use nmh, some have drifted away. 'Nuf said
>on this topic.
>
> o There is a general concensus that
> markus schnalke wrote:
> > (4) no attachments & non-ASCII -> no MIME; the message contains
> > non-ASCII chars; the recipient can not know which charset the
> > non-ASCII chars had been.
> >
> > To cover case 4, one needs to run mime at the whatnow prompt manually.
>
> Yes, and I find t
markus schnalke wrote:
> (4) no attachments & non-ASCII -> no MIME; the message contains
> non-ASCII chars; the recipient can not know which charset the
> non-ASCII chars had been.
>
> To cover case 4, one needs to run mime at the whatnow prompt manually.
Yes, and I find that annoying. M
> Probably parts of what I said were ``lost in translation'' as English
> is not my native language.
>
>
> I explain again what I meant:
>
> Using non-ASCII chars in the mail *body* together with Jon's
> attachment system leads to the following cases:
>
> (1) no attachments & only ASCII -> no M
Probably parts of what I said were ``lost in translation'' as English
is not my native language.
I explain again what I meant:
Using non-ASCII chars in the mail *body* together with Jon's
attachment system leads to the following cases:
(1) no attachments & only ASCII -> no MIME; everything well
> On Thu, Dec 2, 2010 at 12:42 PM, Jon Steinhart wrote:
> > Correct me if my memory is failing me here, I'm being lazy and not rereading
> > rfcs at the moment because I have other things to do.
> >
> > I recall that in the absence of appropriate headers messages are defined as
> > ASCII. If that'
On Thu, Dec 2, 2010 at 12:42 PM, Jon Steinhart wrote:
> Correct me if my memory is failing me here, I'm being lazy and not rereading
> rfcs at the moment because I have other things to do.
>
> I recall that in the absence of appropriate headers messages are defined as
> ASCII. If that's the case,
> English is probably your native language and the one your emails are
> written in.
>
> This way non-ASCII text does not get handled specially (if no
> attachment is present).
>
> No MIMEification means that the characters are plainly in the mail
> body. The original charset is not available in
36 matches
Mail list logo
