 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> Don't worry; you didn't start an argument,
Anyway, it's a discussion and not an argument. :-) It's not officially
an argument until someone gets compared to Hitler. ;-)
--
Darren New, San Diego CA USA (PST)
I am in geosynchronous orbit, supported by
a quantum photon exchange drive....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.407da9166dd1cc255df4252f0@news.povray.org> , "Brian"
<cscibriATyahooDOTcom> wrote:
> To everyone else... I'm sorry for starting a massive
> argument. :-(
You didn't start it as you cannot change the way I implemented the web view.
If it hadn't been your post, it would have been some other with attachment
:-)
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povray org
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407db205$1@news.povray.org> , Darren New <dne### [at] sanrrcom>
wrote:
>> Remember that MIME standards
>> for Multipurpose Internet Mail Extensions.
>
> Yes, and that's why HTTP uses them too, right? ;-)
No, HTTP just the media types defined by MIME. However, HTTP has nothing to
do with MIME messages at all other than that you can of course also transmit
MIME messages with HTTP; not that anything would be able to display the...
> Sure. And if web clients showed you broken content instead of silently
> trying to correct it, a system like Google wouldn't have to incorporate
> every known trick just to work, because the first time the designer
> looked at it they'd see it's broken.
What a great argument. It is not web clients, it is *every* newsreader that
has to do guessing where attachments start if a message is not in MIME
multipart format. And newsreaders (if they are web based or not) would do
you no favour if they would only display 5% of messages, because that is
about the percentage of that correctly follow the MIME standard for
attachments.
> I haven't looked at the web view. Does it allow for mixed text and
> images?
Excuse me? Did you ever notice that most people here post images together
with some comment what the image is or some specific question?
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407db2bc$1@news.povray.org> , Darren New <dne### [at] sanrrcom>
wrote:
> Alright. If you're going to say "I'll generate MIME headers and put them
> on the posts, but you should be smart enough to ignore them because I'm
> delivering the message over NNTP instead of SMTP", then I'll grant you
> that. But in that case, why put the headers on at all?
The text character set encoding. If you don't put one in, newsreaders tend
to assume ASCII plus the local upper page of your character set, which isn't
necessarily ISO-8859-1. However, as I can more or less control that only
ISO-8859-1 characters come through via the web view posting HTML form, it
makes a whole lot of sense to let newsreaders know. The catch is, if you
just put in a Content-Type header without claiming a message to be
compatible with MIME, some newsreaders will ignore the Content-Type header
completely also many will still interpret it correctly.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Dan P wrote:
> > Don't worry; you didn't start an argument,
>
> Anyway, it's a discussion and not an argument. :-) It's not
> officially an argument until someone gets compared to Hitler. ;-)
LOL!!
Oh yeah.. and btw, I'm using OE6 on WinXP and I assume this is the
mainstream newsreader above all mainstream newsreaders.. and it doesn't
decode the message.
Regards,
Hugo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> What a great argument. It is not web clients, it is *every* newsreader that
> has to do guessing where attachments start if a message is not in MIME
> multipart format.
I'm still not understanding why you'd expect the newsreader to ignore a
content-type of text/plain but obey a content-type of multipart/*?
> And newsreaders (if they are web based or not) would do
> you no favour if they would only display 5% of messages, because that is
> about the percentage of that correctly follow the MIME standard for
> attachments.
I find that most all messages either post correct MIME, or leave off the
mime headers, at which point the client tries to guess based on content.
I find that the clients that try to guess content in spite of MIME
headers saying what the content are are the clients that are
traditionally most heinously insecure because of that, which is why I
don't use them.
On the other hand, Mozilla 1.6 (arguably one of the popular clients)
doesn't understand begin-base64, so the point is moot.
> Excuse me? Did you ever notice that most people here post images together
> with some comment what the image is or some specific question?
Sure. Does that mean I bothered to look to see where they're posting it
from? :-) It wasn't an accusation, it was a question.
> The text character set encoding.
OK. I'm boggled by the concept that a client should, based on the
protocol used to retrieve the message, obey a content-type multipart/*,
ignore *half* of the content-type text/plain, and ... um ... what about
other content types? What would you do?
> The catch is, if you
> just put in a Content-Type header without claiming a message to be
> compatible with MIME, some newsreaders will ignore the
> Content-Type header
> completely also many will still interpret it correctly.
But you want them to ignore half the content type, apparently? :-)
--
Darren New, San Diego CA USA (PST)
I am in geosynchronous orbit, supported by
a quantum photon exchange drive....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <407e9f74@news.povray.org> , Darren New <dne### [at] sanrrcom> wrote:
>> What a great argument. It is not web clients, it is *every* newsreader that
>> has to do guessing where attachments start if a message is not in MIME
>> multipart format.
>
> I'm still not understanding why you'd expect the newsreader to ignore a
> content-type of text/plain but obey a content-type of multipart/*?
I don't *expect* newsreaders to do anything. I am just quoting a fact, is
that really so difficult to grasp?
> I find that most all messages either post correct MIME
That is because you don't know the MIME specification!
> I find that the clients that try to guess content in spite of MIME
> headers saying what the content are are the clients that are
> traditionally most heinously insecure because of that, which is why I
> don't use them.
Sorry, but you just don't know what you are talking about here. If your
client won't be guessing, you couldn't see most of the messages on this
server at all.
> On the other hand, Mozilla 1.6 (arguably one of the popular clients)
> doesn't understand begin-base64, so the point is moot.
Indeed.
> OK. I'm boggled by the concept that a client should, based on the
> protocol used to retrieve the message, obey a content-type multipart/*,
> ignore *half* of the content-type text/plain, and ... um ... what about
> other content types? What would you do?
You really don't want to understand what I am saying, you you? It does not
matter what anybody *expects*! I am just saying what clients do! And we
cannot change what clients do, now can we? So we have to deal with it.
> > The catch is, if you
> > just put in a Content-Type header without claiming a message to be
> > compatible with MIME, some newsreaders will ignore the
> > Content-Type header
> > completely also many will still interpret it correctly.
>
> But you want them to ignore half the content type, apparently? :-)
Sorry, but now you repeated the same nonsense three times in this message...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>>>What a great argument. It is not web clients, it is *every* newsreader that
>>>has to do guessing where attachments start if a message is not in MIME
>>>multipart format.
>>
>>I'm still not understanding why you'd expect the newsreader to ignore a
>>content-type of text/plain but obey a content-type of multipart/*?
>
> I don't *expect* newsreaders to do anything. I am just quoting a fact, is
> that really so difficult to grasp?
Well, you're claiming that every newsreader has to do this, and that
isn't true. What I think you're saying is that in order to display every
possible form of "attachment", the newsreader must sometimes look at the
content of messages declared as "text/plain" explicitly, in order to see
if that header is accurate.
Which is fine, if that's what you want to require. I just think it's
quite unusual to expect that.
>>I find that most all messages either post correct MIME
>
> That is because you don't know the MIME specification!
Of course I do. I've been writing programs that read and write MIME
messages for longer than the WWW has been around. I worked for the guy
who invented MIME while I did that. Many times I telnetted to an SMTP
server and typed MIME multipart messages directly into the mail server.
I've written mail-driven online shopping malls. I'm pretty sure I
understand how MIME works.
Admittedly, there's no specific RFC that says MIME should be applied to
messages delivered via NNTP. But if you claim a message is
MIME-complient in an NNTP-based message, I think it's reasonable
behavior for the mail reader to take your word for that and not go
groping around for non-MIME attachments in the middle.
If you don't think that's reasonable, power to you. It's your server,
and I'm not about to browbeat you over it. :-) I just won't be looking
at most of those posts.
>>I find that the clients that try to guess content in spite of MIME
>>headers saying what the content are are the clients that are
>>traditionally most heinously insecure because of that, which is why I
>>don't use them.
>
>
> Sorry, but you just don't know what you are talking about here. If your
> client won't be guessing, you couldn't see most of the messages on this
> server at all.
No, most of them either aren't labeled as MIME-complient, or they use
MIME correctly. It's the half-and-half bit that doesn't work right on
this client. If you post a uuencoded message with no mime headers, the
client I'm using tries to guess.
And what I was referring to in that particular paragraph is the tendency
for Outlook et al to run executable programs when the content type
doesn't match the extension on the file, which is where many many many
of the viri currently circulating come from.
>>OK. I'm boggled by the concept that a client should, based on the
>>protocol used to retrieve the message, obey a content-type multipart/*,
>>ignore *half* of the content-type text/plain, and ... um ... what about
>>other content types? What would you do?
>
>
> You really don't want to understand what I am saying, you you? It does not
> matter what anybody *expects*! I am just saying what clients do! And we
> cannot change what clients do, now can we? So we have to deal with it.
You're saying what *some* clients do. I saw quite a few posts saying
that their clients couldn't handle it. And there's no need to yell. And
the right way of dealing with clients that accept "broken" messages
isn't to generate "broken" messages, is my point. There are a number of
ways of attaching images to mail messages, and attaching them using
uuencode inside a message declared as mime-complient is probably the
brokennest. I understand *why* you did it; I'm just saying it's the
wrong solution, with the right solution being to bite the bullet and
generate a mime-multipart.
>> > The catch is, if you
>> > just put in a Content-Type header without claiming a message to be
>> > compatible with MIME, some newsreaders will ignore the
>> > Content-Type header
>> > completely also many will still interpret it correctly.
>>
>>But you want them to ignore half the content type, apparently? :-)
>
>
> Sorry, but now you repeated the same nonsense three times in this message...
I don't see what's nonsensical about it. You think they should look at
something, show half of it as text in the character set you suggested,
and decode the other half. I'm saying "that's a bad way to do it, given
the other standards about that people have actually widely implemented."
Is there any client out there that will display the image in a uuencoded
message inside a MIME message that will *not* handle a mime multipart?
--
Darren New, San Diego CA USA (PST)
I am in geosynchronous orbit, supported by
a quantum photon exchange drive....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote in message
news:Xns94CB4705A1982raf256com@203.29.75.35...
> cscibriATyahooDOTcom news:web.407cc06d10b5e3da5df4252f0@news.povray.org
>
> I think that You should
>
> 1. use MIME encoding attachments
> 2. rather use jpeg instead of PNG
>
didn't that whole jpeg2000 debacle in pov.general determine that the 3
prefered formats for pov.binaries.images is either GIF, JPEG, or PNG?
People can post png's all they want, as far as i'm concerned, if this is
true.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Base 64.
>
> Yeah, that is what it says. But how to decode that one?
> With UUencode I can stil read the image in winzip,
> this one it does not know.
A = 000000
B = 000001
C = 000011
...
Z = 011001
a = 011010
b = 011011
...
z = 110011
0 = 110100
1 = 110101
2 = 110110
...
9 = 111101
+ = 111110
/ = 111111
Easy!
(This was in the exam for my final year at uni... yes, we actually had
to Base-64 encode and decode stuff in the exam room!)
Andrew @ home.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
