Subject: Re: The <cid: ...> URL - who implements it?
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Mon, 05 Mar 2001 09:39:42 -0800 (PST)
List-Id: <ietf-822.imc.org>

> In <[email-masked]> Simon Josefsson <[email-masked]> writes:

> >Another idea to throw into this thread would be RFC 2387 on the
> >text/x-okie MIME type, which seem to be a solution to this problem.
> >It's only used as an example in the RFC, and I do not know if anything
> >became of the text/x-okie idea, but it shows that others has
> >considered this to be a problem worth solving before.

> OK, but it does introduce a worry that people are defining all sorts of
> very specialized Mime extensions for perceived applications, without
> looking for more generalized extensions that will cover a whole class of
> applications, which implementors of browsers would be more likely to
> support.

> And how is it that an official RFC has managed to define a token staring
> with "x"?

It didn't. It is simply an example of something you could do, not a definition
of anything. That's why it is an x- type and not something that could be
registered.

				Ned

To: [email-masked]
Xref: clerew local.mime:552
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: The <cid: ...> URL - who implements it?
Date: Mon, 5 Mar 2001 11:31:42 GMT
Lines: 28
Sender: [email-masked]

In <[email-masked]> Simon Josefsson <[email-masked]> writes:

>Another idea to throw into this thread would be RFC 2387 on the
>text/x-okie MIME type, which seem to be a solution to this problem.
>It's only used as an example in the RFC, and I do not know if anything
>became of the text/x-okie idea, but it shows that others has
>considered this to be a problem worth solving before.

OK, but it does introduce a worry that people are defining all sorts of
very specialized Mime extensions for perceived applications, without
looking for more generalized extensions that will cover a whole class of
applications, which implementors of browsers would be more likely to
support.

And how is it that an official RFC has managed to define a token staring
with "x"?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked] (Charles Lindsey)
Cc: [email-masked]
Subject: Re: The <cid: ...> URL - who implements it?
From: Simon Josefsson <[email-masked]>
Date: 03 Mar 2001 23:51:22 +0100
Lines: 48
Sender: [email-masked]

Another idea to throw into this thread would be RFC 2387 on the
text/x-okie MIME type, which seem to be a solution to this problem.
It's only used as an example in the RFC, and I do not know if anything
became of the text/x-okie idea, but it shows that others has
considered this to be a problem worth solving before.

5.2 Text/X-Okie

   The Text/X-Okie is an invented markup language permitting the
   inclusion of images with text.  A feature of this example is the
   inclusion of two additional body parts, both picture. They are
   referred to internally by the encapsulated document via each
   picture's body part content-ID.  Usage of "cid:", as in this example,
   may be useful for a variety of compound objects.  It is not, however,
   a part of the Multipart/Related specification.

     Content-Type: Multipart/Related; boundary=example-2;
             start="<[email-masked]>"
             type="Text/x-Okie"

     --example-2
     Content-Type: Text/x-Okie; charset=iso-8859-1;
             declaration="<[email-masked]>"
     Content-ID: <[email-masked]>
     Content-Description: Document

     {doc}
     This picture was taken by an automatic camera mounted ...
     {image file=cid:[email-masked]}
     {para}
     Now this is an enlargement of the area ...
     {image file=cid:950118:[email-masked]}
     {/doc}
     --example-2
     Content-Type: image/jpeg
     Content-ID: <[email-masked]>
     Content-Transfer-Encoding: BASE64
     Content-Description: Picture A

     [encoded jpeg image]
     --example-2
     Content-Type: image/jpeg
     Content-ID: <[email-masked]>
     Content-Transfer-Encoding: BASE64
     Content-Description: Picture B

     [encoded jpeg image]
     --example-2--