rhys | 5 Jul 00:43 1993
Picon

MIME and Microsoft Windows

I haven't seen an announcement on this list as yet, so this message is to
let you know that a new Internet Draft, authored by myself, is available.
It's title is "MIME Content-Types for Microsoft Windows".  Eventually I
hope this will become an informational RFC (modulo any flames that may erupt
on the list. :-)  The draft is available in the usual places, with the
filename "draft-ietf-822ext-microsoft-window-00.txt".  If there is enough
demand, I'll send a copy to the list.

In brief, the intention (of the final RFC) is to register Content-Types for
a number of file formats used in the Microsoft Windows environment and to
specify conversions that can be performed to aid interoperability.  The list
of Content-Types is by no means complete, and further additions are welcome,
provided that descriptions of additional formats already exist in other
places (SDK manuals, etc).

Cheers,

Rhys.

Harald Tveit Alvestrand | 5 Jul 14:01 1993
Picon
Picon

Re: Content-Disposition Header

A VERY short note:
my multipart/related draft had multiple types in the "header"
fields. So, HTML and RTF both referencing a GIF would be fine.
(oops - Content-ID, not types. Types would fail if you wanted
one piece of HTML to reference another piece of HTML).

            Hrald A

rhys | 7 Jul 02:24 1993
Picon

(unknown)


Network Working Group                                      R. Weatherley
Internet Draft                                  University of Queensland
                                                              July, 1993

                MIME Content-Types for Microsoft Windows

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.  Internet Drafts are draft
   documents valid for a maximum of six months.  Internet Drafts may be
   updated, replaced, or obsoleted by other documents at any time.  It
   is not appropriate to use Internet Drafts as reference material or to
   cite them other than as a "working draft" or "work in progress".
   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the status of this or any other Internet
   Draft.

   Distribution of this memo is unlimited.

Abstract

   This memo registers MIME [RFC-MIME] Content-Types for a number of
   file formats common to the Microsoft Windows environment.  The
   intention is to aid interoperability between mail systems, and to
   enumerate possible conversions at gateways.

(Continue reading)

Carlyn M. Lowery | 7 Jul 20:51 1993
Picon

Re: Content-Disposition Header

To raise a new issue about the document, I think the definitions of the
terms "inline" and "attachment" need to be improved.  There's a
distinction between semantics and user interface which is blurred in the
document, and the semantics of the terms should be more clearly defined.
 I find it helpful to think of ordinary documents when attempting to make
the distinction.  It seems to me that the intended semantics are
approximately as follows, (though I am still having difficulty with
defining inline):

Body parts labeled as inline are intended to be viewed in the same
context, in order.  Body parts labeled as attachments are intended to be
viewed as separate but related entities.   They are distinct from the main
message, but are intended to be referenced from the main viewing area,
just as one would reference an attachment in the main body of an ordinary
document.

Some specific comments which illustrate problems with the current
definitions are below.

>From the draft:
> A bodypart should be marked 'inline' if it is intended to be displayed
> automatically upon display of the message. Inline bodyparts should be
> displayed in the order in which they are encountered.
> ...
> Bodyparts can be designated 'attachment' to indicate that they are
> separate from the main body of the mail message, and that their
> display should not be automatic, but contingent upon some further
> action of the user.

So, are sound and video supposed to be called inline or attachments?  What
(Continue reading)

John Gardiner Myers | 8 Jul 05:19 1993
Picon

Re: text/enriched comments

sdorner <at> qualcomm.com (Steve Dorner) writes:
> I do this by delimiting the richtext body parts with <x-rich> and
> </x-rich> directives, and then treating the whole thing as (sorta)
> text/richtext.

Don't you mean the "delimiting the text/plain parts"?

This is certainly a legal interpretation of richtext--a richtext
reader can "recognize" any formatting command and if it is not
mentioned in a standard, interpret it anyway it wants.  It can display
the text top-to-bottom, spiraling out of the center, or as morse code
tapped out on the speaker.  As long as you don't *compose* (and send
out) a message that violates the richtext restrictions.

Complicating your parser in order to handle this extension may well be
an overall win for you.  This does not necessarily mean it is good to
require all parsers to be similarly complicated.

How do you handle text/plain parts with imbedded "<x-rich>" and
"</x-rich>" text?

--

-- 
_.John G. Myers		Internet: jgm+ <at> CMU.EDU
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

Andr'e PIRARD | 9 Jul 18:25 1993
Picon

Thoughts about characters transmission

I have not much time to spend on this subject, but I would have felt bad
not to express these opinions once.

I have learned with much interest that people envision solutions for
international characters data exchange with a wider point of view than
usually heard in the networking sphere.
I have been spending quite a time of my life with such problems.
I thought I could contribute with a small text explaining the way
I have finally come to think of the problem.
Nothing totally new, probably, but a different shed of light, maybe.
The text may sound theoretical at first. It is just terse. The ideas are
based on experience. They have been put to use in the field of 8-bit
characters. I participated to the design of Kermit multinational 8-bit
characters support and the TCP/IP network I work for is well on the way
towards the the same theory that every character on the communication
line is ISO 8859-1. Any exception to this, like translating EBCDIC directly
to PC code on one machine, is considered harmful to our internetworking,
even if convenient.
Every piece working towards a common well defined goal finally pays more
when all parts start to clutch than wandering for immediate interest.
And I hope that saying that my language is French will make the ideas
in a difficult to write text even more convincing, despite being short.

Networking has had for long the problem of a common representation of
computer-specific data (numbers, bit strings...) on the wire (rather, on the
connection), because different computers had different conventions for them.
To solve this problem, rules like XDR (external data representation) have
been devised, and, because it was so important, the rules have been adopted.

Character data caused little problem because ASCII was assumed, full stop.
(Continue reading)

Keld J|rn Simonsen | 10 Jul 10:31 1993
Picon

Re: Thoughts about characters transmission

Andr'e PIRARD writes:

> The _most_important_point_ is that a single common representation code
> be defined _for_the_line_ (suiting the purpose, namely to cover all national
> languages in one single way) and that people be instructed that every bit
> of text should travel in that code on the wire, whatever_the_protocol_is.

I agree to most of what Andre'' is saying and I have an additional
point here: that the single common representation code should be something
that can be handled by existing software and hardware, because it
will take a long time before the conversion software is installed
on all machines, or even a large share of the installed base.
Also I would like to emphasis the need for world-wide solutions.
This would mean that ISO 8859-1 would not be a good candidate,
we need something ASCII based (or even with a smaller repertoire
than ASCII to cover the problems with EBCDIC and national ISO 646 
variants).

I have proposed such a solution in RFC1345.

Keld

Rick Troth | 10 Jul 19:02 1993

Re: Thoughts about characters transmission

        [please excuse this cross-post;  I am following a thread]

>> The _most_important_point_ is that a single common representation code
>> be defined _for_the_line_ (suiting the purpose, namely to cover all national
>> languages in one single way) and that people be instructed that every bit
>> of text should travel in that code on the wire, whatever_the_protocol_is.
>
>I agree to most of what Andre'' is saying and I have an additional
>point here: that the single common representation code should be something
>that can be handled by existing software and hardware,   ...

        I agree with most of what Andr) said,  and agree with you on
this one point.   But ...

>will take a long time before the conversion software is installed
>on all machines, or even a large share of the installed base.
>Also I would like to emphasis the need for world-wide solutions.
>This would mean that ISO 8859-1 would not be a good candidate,
>we need something ASCII based (or even with a smaller repertoire
>than ASCII to cover the problems with EBCDIC and national ISO 646
>variants).

        I don't understand the warrant here,  Keld.   You're right that
we need world-wide solutions and you're right that we should have some-
thing ASCII based.   How does these make ISO 8859-1 a bad choice?

        I've spent a significant part of *my* life working with others
toward a true solution to the  ASCII <---> EBCDIC  problem.   Some form
of concensus was reached a long time ago and folks have successfully
"beat IBM over the head"  with it,  and IBM has finally acknowledged a
(Continue reading)

Keld J|rn Simonsen | 11 Jul 10:24 1993
Picon

Re: Thoughts about characters transmission

Rick Troth writes:

> >Also I would like to emphasis the need for world-wide solutions.
> >This would mean that ISO 8859-1 would not be a good candidate,
> >we need something ASCII based (or even with a smaller repertoire
> >than ASCII to cover the problems with EBCDIC and national ISO 646
> >variants).
> 
>         I don't understand the warrant here,  Keld.   You're right that
> we need world-wide solutions and you're right that we should have some-
> thing ASCII based.   How does these make ISO 8859-1 a bad choice?

Because 8859-1 does not run on every computer in the world, and we
cannot expect it to do so, ever. 8859-1 is for western Europe.
Mandating 8859-1 would introduce the same problems for the
rest of the world that Western Europe (where I live) have had 
for decades with ASCII.

>         I've spent a significant part of *my* life working with others
> toward a true solution to the  ASCII <---> EBCDIC  problem.   Some form
> of concensus was reached a long time ago and folks have successfully
> "beat IBM over the head"  with it,  and IBM has finally acknowledged a
> "de facto network EBCDIC"  [my term]  which they call CodePage 1047.
> CP 1047 maps one-for-one with ISO 8859-1.   The mapping of 1047/8859-1
> is the most palatable mapping to the most sites on the InterNet.

It only works for Western European languages.

Keld

(Continue reading)

Masataka Ohta | 12 Jul 02:49 1993
Picon

Re: Thoughts about characters transmission

> I participated to the design of Kermit multinational 8-bit
> characters support and the TCP/IP network I work for is well on the way
> towards the the same theory that every character on the communication
> line is ISO 8859-1.

I quite agree with you. In Europe and in US, it is too much true.

> Now that the international character code ISO 10646 is out, isn't it time
> for communication systems to be able to not only exchange pictures and sound
> but also plain text?  Will ISO 10646 be used by OSI 6?

The problem is that, from the view point outside of Europe and US, ISO
10646 is merely a poor extension to ISO 8859-1.

It assignes a single code point to different but similar characters
in Japan and China.

So, please don't say "international" when what you mean is merely
"intereuropean".

							Masataka Ohta


Gmane