Subject: Re: Standards for machine translation in e-mail andnetnews
From: Keith Moore <[email-masked]>
To: [email-masked]
Cc: Jacob Palme <[email-masked]>, IETF mailing list on MIME and e-mail <[email-masked]>
Date: Wed, 14 Feb 2001 01:04:48 -0500
List-Id: <ietf-822.imc.org>

[recipient list trimmed]

> I don't understand what multipart/choices is for. There are
> implementation problems for multipart/alternative, but they
> don't get fixed by proposing something new. They can (and
> should) just be fixed asap, which is easier than to implement
> something new.

I would further argue that "something new" in this space which is 
so similar to multipart/alternative serves merely to increase the 
number of implementation options, and thus, to decrease the 
liklihood of interoperability.

Keith

Reply-To: [email-masked]
Date: Wed, 14 Feb 2001 12:20:04 +0900
To: Jacob Palme <[email-masked]>, [email-masked], IETF mailing list on MIME and e-mail  <[email-masked]>, <[email-masked]>
From: Martin Duerst <[email-masked]>
Subject: Re: Standards for machine translation in e-mail andnetnews
Cc: "Phil Scanlan" <[email-masked]>, <[email-masked]>, Keld J =?ISO-2022-JP?B?GyRCeHIbKEI=?=n Simonsen <[email-masked]>, Brian Garr <[email-masked]>, Nick  Shelness <[email-masked]>, "Pierre-Yves Focou.  \"PY FOUCOU\"" <[email-masked]>, Francisco Sparta <[email-masked]>, Andrew Shuttleworth <[email-masked]>, Portal Coordination <[email-masked]>, REIS Mailing List <[email-masked]>, [email-masked]
Sender: [email-masked]

Hello Jacob,

I have just had a short look at this. A few comments.

I don't understand what multipart/choices is for. There are
implementation problems for multipart/alternative, but they
don't get fixed by proposing something new. They can (and
should) just be fixed asap, which is easier than to implement
something new.

Please also note that the 'selector' parameter is very similar
to the 'differences' parameter proposed in RFC 1766
(e.g. http://www.innosoft.com/rfc/rfc1766.html), which yet
has to take on. It would at least be worthwhile to use the
same name.

For ftp://ftp.dsv.su.se/users/jpalme/draft-palme-email-translation-02.txt,
it says "All of these methods of transmitting information is based on the
assumption that all language versions are ready and available when a
message is sent.". This is clearly wrong, because it doesn't
apply to http. It may also be worth mentioning that some formats,
in particular SVG (http://www.w3.org/TR/SVG/struct.html#SwitchElement)
and SMIL (http://www.w3.org/TR/REC-smil/#switch), have a <switch>
construct that allows to display one of the languages contained
in the document.

The provisions regarding the "Content-Translator" header field:
 >>>>
   The "Content-Translator" header field indicates who made the
   translation. When a translation is submitted, the "From" header field
   should still indicate the original author, but the "Content-Translator"
   header field can indicate who made the translation.
 >>>>
are very scary, because they will produce very misleading impression
on user agents that don't understand Content-Translator (namely
that the mail came from the original sender). Things should be
turned around, so that such an impression is not possible.

In general, I think that translations, in particular incremental
ones, fit much better with the Web paradigm than with the message
paradigm. It might be better to get some more actual experience
on the Web side rather than to try to force things into messaging.

Regards,   Martin.

At 11:09 01/02/13 +0100, Jacob Palme wrote:
>Work on standards for language-translation in e-mail and netnews can
>take place in the mailing list [email-masked].
>
>To subscribe to this mailing list, send a message to [email-masked]
>which contains the text SUB[SCRIBE] LANGTRANS
>
>When your subscription has been accepted, please write a short message
>to the list describing yourself and your interest in languate translation 
>standards.
>
>More information and the present IETF drafts can be downloaded from
>http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#translation
>
>The web page above earlier gave an incorrect description of how
>to join the mailing list. This has been corrected.
>--
>Jacob Palme <[email-masked]> (Stockholm University and KTH)
>for more info see URL: http://www.dsv.su.se/jpalme/

Date: Tue, 13 Feb 2001 11:09:47 +0100
To: [email-masked], IETF mailing list on MIME and e-mail  <[email-masked]>, <[email-masked]>, <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Standards for machine translation in e-mail and netnews
Cc: "Phil Scanlan" <[email-masked]>, <[email-masked]>, Keld Jørn Simonsen <[email-masked]>, Brian Garr <[email-masked]>, Nick Shelness <[email-masked]>, "Pierre-Yves Focou.  \"PY FOUCOU\"" <[email-masked]>, Francisco Sparta <[email-masked]>, Andrew Shuttleworth <[email-masked]>, Portal Coordination <[email-masked]>, REIS Mailing List <[email-masked]>, [email-masked]
Sender: [email-masked]

Work on standards for language-translation in e-mail and netnews can
take place in the mailing list [email-masked].

To subscribe to this mailing list, send a message to [email-masked]
which contains the text SUB[SCRIBE] LANGTRANS

When your subscription has been accepted, please write a short message
to the list describing yourself and your interest in languate 
translation standards.

More information and the present IETF drafts can be downloaded from
http://dsv.su.se/jpalme/ietf/jp-ietf-home.html#translation

The web page above earlier gave an incorrect description of how
to join the mailing list. This has been corrected.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 12 Feb 2001 18:36:07 +0100
To: [email-masked], IETF working group on HTML in e-mail <[email-masked]>
From: Jacob Palme <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Sender: [email-masked]

At 21.51 +0000 01-02-09, Charles Lindsey wrote:
>  >If there is a wish for this to be made a standard, where
>>should it be specified? In a revised version of the MHTML
>>standard (RFC 2110) or in a revised version of the
>>Content-ID standard (RFC 2111) or a new separate RFC
>>on this topic. If you intend to combine "cid:" with
>>"Multipart/related" then a revised version of RFC 2110
>>might be the best place for this.
>
>I think an extension to RFC 2110 would be the proper course, if it were
>agreed than an RFC was necessary. But whatever is done, if it allows these
>particular URLs to be recognised within text/plain (or text/something).
>then it should allow for ANY URL to be recognised in text/plain (since
>many systems currently attempt to do it ad hoc, and usually
>sort-of-successfully).

Is it the general opinion that such an extension of RFC 2110
is desirable?

In the case of absolute URLs of the http://foo.bar/file.ext type, it
has already become common practice that such URLs are interpreted as
links in e-mail even if they are not framed as in
<URL:http://foo.bar/file.ext>.

But I guess you are thinking of relative URLs, where the main text
could say:

... for more info, see <URL:attach-one.html> ...

and the next body part would then have

Content-Location: attach-one.html

Your proposal actually raises two issues:

(1) A standard for interpreting URLs in text/plain,
     possible combined with an attribute, for example
     Content-Type: text/plain; URL=interpret

(2) To use RFC 2110 to send a set of linked pages.

Of these items, (2) does not really require any change
to RFC 2110, it just requires that implementors decide
to implement this way of using RFC 2110.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Mon, 12 Feb 2001 09:58:45 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Sender: [email-masked]

On Fri, 9 Feb 2001, Charles Lindsey <[email-masked]> wrote:
>In <p0501041fb6a87853966b@[130.237.150.141]> Jacob Palme <[email-masked]> 
>writes:

>>This might be a solution, although a problem is that many
>>mailers handle all body parts except the first as attachments,
>>even if they have Content-Disposition: Inline on them.
>
>Turnpike is the only mail/news reader I know of that handles multiparts
>truly inline 

I'm sure there is more than one!

>(you can even change Content-ID several times within the same
>line if you are careful). They claim, of course, that theirs is the only
>true implementation of Mime, 

We have never claimed that it is the "only true implementation of Mime". 

Turnpike does not generate messages with consecutive text multipart
sections on the same text line (i.e. all text/* generated by Turnpike
are terminated with CRLF). However, if it were to receive such a
message, with consecutive text/* parts without terminating CRLFs, it
would interpret the text as being on a single line.

I would say that such an implementation is a _reasonable_ interpretation
of MIME, and probably even a natural one. Generating such things is a
different matter, of course.

>>It is somewhat more restricted than HTML in that you
>>cannot mix picture and text in the same text line.
>
>Turnpike can.

No it can't - it will only concatenate consecutive text/* parts that
lack intermediate CRLFs.

-- 
Ian Bell                                           T U R N P I K E

To: [email-masked]
Xref: clerew local.mime:548
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: The <cid: ...> URL - who implements it?
Date: Fri, 9 Feb 2001 21:51:04 GMT
Lines: 91
Sender: [email-masked]

In <p0501041fb6a87853966b@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>Simon J points out (see below) that there already is a
>format for hyperlinks in plain text, the format like

>   <URL:http://www.ietf.cnri.reston.va.us/rfc/rfc1738.txt?number=1738>

>So if this is to be recommended for URLs in e-mail, and extended
>to also support "cid:" URLs, something like

>   <URL:cid:<[email-masked]>

>might be explicitly specified in some future standard.

Yes, that would presumably be the format to adopt. However, I have come
round to the opinion that RFC2110 mechanisms (using Content-Location)
would be more suitable for this particular application that CID
mechanisms, simply because of the requirement that Content-IDs have to be
globally unique, which is unnecessary (and even a nuisance) for this
particular purpose.

>However, my experience from my personal usage of HTML in
>e-mail is that there are other very useful uses of HTML
>in e-mail. I personally use HTML in e-mail only when I am
>replying to a personal message in HTML format, or when
>I have special needs for HTML facilities. The special
>needs for HTML facilities occurs mainly in two cases:

>(a) I want to include one or more in-line pictures in
>     my message.

>(b) I want to quote formatted text from some source
>     such as a book or web page, and want to show the
>     formatting in the original source.

I think those are two cases where sending the mail in HTML format would be
appropriate, since you would presumably already be aware that your
correspondent had some capability to display pictures and texts formatted
in that particular way. But it would not be appropriate for normal day-to
day email.

However, it would not be appropriate in News (though technically workable,
of course) because the rules or customs which govern particular newsgroups
or hierarchies tend to prohibit binaries (e.g. pictures) or fancy
formatting. And of course on News you cannot make any assumptions at all
as to what your readers are able to display (except that people who
subscribe to alt.binaries.pictures can presumably display them somehow).

>This might be a solution, although a problem is that many
>mailers handle all body parts except the first as attachments,
>even if they have Content-Disposition: Inline on them.

Turnpike is the only mail/news reader I know of that handles multiparts
truly inline (you can even change Content-ID several times within the same
line if you are careful). They claim, of course, that theirs is the only
true implementation of Mime, but the rest of the world seems unconvinced
:-( .

>It is somewhat more restricted than HTML in that you
>cannot mix picture and text in the same text line.

Turnpike can.

>If there is a wish for this to be made a standard, where
>should it be specified? In a revised version of the MHTML
>standard (RFC 2110) or in a revised version of the
>Content-ID standard (RFC 2111) or a new separate RFC
>on this topic. If you intend to combine "cid:" with
>"Multipart/related" then a revised version of RFC 2110
>might be the best place for this.

I think an extension to RFC 2110 would be the proper course, if it were
agreed than an RFC was necessary. But whatever is done, if it allows these
particular URLs to be recognised within text/plain (or text/something).
then it should allow for ANY URL to be recognised in text/plain (since
many systems currently attempt to do it ad hoc, and usually
sort-of-successfully).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131      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]
Xref: clerew local.mime:546
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: The <cid: ...> URL - who implements it?
Date: Thu, 8 Feb 2001 20:45:03 GMT
Lines: 57
Sender: [email-masked]

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

>[email-masked] (Charles Lindsey) writes:

>> What I am after is the regularisation of the present practice whereby
>> software attempts to recognise URLs when it finds them in the midst of
>> text/plain (usually by recognising anything starting with "www." or
>> enclosed in <...>).

>Isn't the text in an appendix of RFC1738 (which I quoted earlier in
>this thread) sufficient to solve this problem?

BTW, one should be speaking of RFC 2396, which has superseded RFC 1738.
But in fact it contains the same text on this matter.

Yes, but that text is a sort of "if you are going to do it, then do it
like this", but it is not clear whether that was intended as advice to
those about to write RFCs for extra features, or whether it was intended
for implementors of existing facilities (like text/plain). I have tried to
follow that text when constructing my examples, and so I wrote
	<url:Q1>
which is syntactically fine ("Q1" is a valid relativeURL according to
RFC1808, and its use in that sort of context is sanctioned by RFC 2110.
Nevertheless, at least one system that has been reported to me tried to
interpret it as <url:http:Q1> (but at least it was the only system so far
that is reported as having recognised it as a URL at all). One of the
oddities of RFC 2110 is that it defines a nice new usage, but does not
provide a "scheme name" for it.

So the question arises as to whether that sort of thing can reasonably be
done as part of "current best practice" - i.e. we just have to persuade
implementors to do it. Or whether it needs an RFC (best practice,
experimental protocol, proposed standard?) perhaps with some extra syntax
like the format=url parameter for text/plain that I suggested (not that I
am suggesting that exact syntax).

It was to hear opinions as to the necessity or otherwise of such an RFC
that I came to this list. So more opinions, please!

>Recommending mail client implementators to support it inside
>text/plain parts would reach the same goal as defining a "format=url"
>flag, without the hassle of introducing a new flag.  If mail client
>implementators wouldn't implement the recommendation, they probably
>wouldn't implement a "format=url" flag either.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131      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

Date: Thu, 8 Feb 2001 18:49:44 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Cc: IETF working group on HTML in e-mail <[email-masked]>
Sender: [email-masked]

I still think it is better to use HTML than to invent a new
markup language based on text with some URL support. If, however
there is a large wish for such a simplified markup language,
this could of course be done.

Two examples of use of HTML in e-mail, which shows the
benefits of HTML compared to plain text in some cases,
can be found at:

     http://dsv.su.se/jpalme/ietf/mhtml-example-1.html and
     http://dsv.su.se/jpalme/ietf/mhtml-example-2.html

Simon J points out (see below) that there already is a
format for hyperlinks in plain text, the format like

   <URL:http://www.ietf.cnri.reston.va.us/rfc/rfc1738.txt?number=1738>

So if this is to be recommended for URLs in e-mail, and extended
to also support "cid:" URLs, something like

   <URL:cid:<[email-masked]>

might be explicitly specified in some future standard.

Charles Lindsey proposes this as a method to send a message
with a list of links to information in other body parts.
The functionality for this would be rather similar to ordinary
mail attachments, but with added functionality to put the
link into the right context in the text. This is not unreasonable,
provided that you hate text/html but still want some of its
functionality.

However, my experience from my personal usage of HTML in
e-mail is that there are other very useful uses of HTML
in e-mail. I personally use HTML in e-mail only when I am
replying to a personal message in HTML format, or when
I have special needs for HTML facilities. The special
needs for HTML facilities occurs mainly in two cases:

(a) I want to include one or more in-line pictures in
     my message.

(b) I want to quote formatted text from some source
     such as a book or web page, and want to show the
     formatting in the original source.

So it is not good that the proposal for URLs in ordinary
text does not support neither of these uses. The most important
of them is in-line pictures.

There is another way of putting in-line pictures in MIME.
This is to have a series of body parts:

(1) Text before first picture in text/plain format
(2) The in-line picture as image/gif format
(3) Text after the first picture in text/plain format

This might be a solution, although a problem is that many
mailers handle all body parts except the first as attachments,
even if they have Content-Disposition: Inline on them.

It is somewhat more restricted than HTML in that you
cannot mix picture and text in the same text line.

----

If there is a wish for this to be made a standard, where
should it be specified? In a revised version of the MHTML
standard (RFC 2110) or in a revised version of the
Content-ID standard (RFC 2111) or a new separate RFC
on this topic. If you intend to combine "cid:" with
"Multipart/related" then a revised version of RFC 2110
might be the best place for this.

What are the opinions of implementors of mail and news
clients? Would you implement this if it is made a standard?

Do you want me to produce a revision of RFC 2110 where
this is added?

At 11.24 +0000 01-02-07, Charles Lindsey wrote:
>  >It seems silly to invent a new rich text format just because you
>>dislike HTML. Would it not be better, instead, to analyze the reasons
>>you dislike HTML, and specify a subset of HTML including restrictions
>>on where to use it, which satisfies your needs but avoids what you
>>dislike in HTML. If such a subset of HTML could be defined and avoids
>>your problems with HTML, it would allow reading software to use the
>>same code for interpreting full HTML and the subset you allow.
>>So only the producing software need to be rewritten to support
>>the new format.
>
>But that is no solution. There would be no way to enforce adherence to
>such a subset, and you grossly under-estimate the pathological hatred of
>HTML when people try to use it on Usenet.

At 14.02 +0100 01-02-02, Simon Josefsson wrote:
><URL:...> could be used inside plain text.  From RFC1738:
>
>APPENDIX: Recommendations for URLs in Context
>
>    URIs, including URLs, are intended to be transmitted through
>    protocols which provide a context for their interpretation.
>
>    In some cases, it will be necessary to distinguish URLs from other
>    possible data structures in a syntactic structure. In this case, is
>    recommended that URLs be preceeded with a prefix consisting of the
>    characters "URL:". For example, this prefix may be used to
>    distinguish URLs from other kinds of URIs.
>
>    In addition, there are many occasions when URLs are included in other
>    kinds of text; examples include electronic mail, USENET news
>    messages, or printed on paper. In such cases, it is convenient to
>    have a separate syntactic wrapper that delimits the URL and separates
>    it from the rest of the text, and in particular from punctuation
>    marks that might be mistaken for part of the URL. For this purpose,
>    is recommended that angle brackets ("<" and ">"), along with the
>    prefix "URL:", be used to delimit the boundaries of the URL.  This
>    wrapper does not form part of the URL and should not be used in
>    contexts in which delimiters are already specified.
>
>    In the case where a fragment/anchor identifier is associated with a
>    URL (following a "#"), the identifier would be placed within the
>    brackets as well.
>
>    In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
>    need to be added to break long URLs across lines.  The whitespace
>    should be ignored when extracting the URL.
>
>    No whitespace should be introduced after a hyphen ("-") character.
>    Because some typesetters and printers may (erroneously) introduce a
>    hyphen at the end of line when breaking a line, the interpreter of a
>    URL containing a line break immediately after a hyphen should ignore
>    all unencoded whitespace around the line break, and should be aware
>    that the hyphen may or may not actually be part of the URL.
>
>    Examples:
>
>       Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
>       type=d> but you can probably pick it up from <URL:ftp://ds.in
>       ternic.net/rfc>.  Note the warning in <URL:http://ds.internic.
>       net/instructions/overview.html#WARNING>.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

To: [email-masked] (Charles Lindsey)
Cc: [email-masked]
Subject: Re: The <cid: ...> URL - who implements it?
From: Simon Josefsson <[email-masked]>
Date: 07 Feb 2001 18:15:32 +0100
Lines: 21
Sender: [email-masked]

[email-masked] (Charles Lindsey) writes:

> What I am after is the regularisation of the present practice whereby
> software attempts to recognise URLs when it finds them in the midst of
> text/plain (usually by recognising anything starting with "www." or
> enclosed in <...>).
>
> One can visualise a situation where, with a suitable "format=url"
> parameter to text/plain, one could say that conforming software SHOULD
> recognise anything of the form "<xxx:.....>" as a URL, and MAY attempt to
> recognise other cases. One might provide restrictions on what "xxx" could
> be ("url" and "uri" would be the minimal candidates, obviously).

Isn't the text in an appendix of RFC1738 (which I quoted earlier in
this thread) sufficient to solve this problem?

Recommending mail client implementators to support it inside
text/plain parts would reach the same goal as defining a "format=url"
flag, without the hassle of introducing a new flag.  If mail client
implementators wouldn't implement the recommendation, they probably
wouldn't implement a "format=url" flag either.

To: [email-masked]
Xref: clerew local.mime:544
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: The <cid: ...> URL - who implements it?
Date: Wed, 7 Feb 2001 11:24:59 GMT
Lines: 68
Sender: [email-masked]

In <p05010411b6a578bf5af0@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>At 11.55 +0000 01-02-05, Charles Lindsey wrote:
>>
>>So this still leave the question of how to send a digest (or other
>>multipart) in either mail or news and to include with it some text
>>explaining what it is about and including pointers to the individual
>>digest items (whether in the form of a table of contents, or otherwise).
>>
>>That sounds like a useful thing to do, and it would seem that URLs
>>identifying the items by their Content-ID is the proper way to do it, and
>>the <cid: ...> URL seems to be the proper one for the job.

Actually, I have now read RFC 2110, and I see that Content-Location would
be a more suitable tool than Content-ID. But otherwise my argument stands.

>What you are doing is inventing a new mark-up language for
>mail and news, in addition to the existing richtext and HTML
>mark-up languages.

Yes, a slightly extended text/plain. There is precedent for that in
Gelens' format=flowed parameter to text/plain (I forget the RFC number).

>It seems silly to invent a new rich text format just because you
>dislike HTML. Would it not be better, instead, to analyze the reasons
>you dislike HTML, and specify a subset of HTML including restrictions
>on where to use it, which satisfies your needs but avoids what you
>dislike in HTML. If such a subset of HTML could be defined and avoids
>your problems with HTML, it would allow reading software to use the
>same code for interpreting full HTML and the subset you allow.
>So only the producing software need to be rewritten to support
>the new format.

But that is no solution. There would be no way to enforce adherence to
such a subset, and you grossly under-estimate the pathological hatred of
HTML when people try to use it on Usenet.

>If, for example, you dislike HTML because it is dificult to read
>for those who read it as plain text, it might be possible to
>define a way of using HTML to avoid this problem.

>An example of such human-readable HTML coding is shown below:

And your example already introduces more extraneous material that many
Usenet readers would be willing to tolerate.

What I am after is the regularisation of the present practice whereby
software attempts to recognise URLs when it finds them in the midst of
text/plain (usually by recognising anything starting with "www." or
enclosed in <...>).

One can visualise a situation where, with a suitable "format=url"
parameter to text/plain, one could say that conforming software SHOULD
recognise anything of the form "<xxx:.....>" as a URL, and MAY attempt to
recognise other cases. One might provide restrictions on what "xxx" could
be ("url" and "uri" would be the minimal candidates, obviously).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131      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

Date: Tue, 6 Feb 2001 11:09:11 +0100
To: [email-masked]
From: Jacob Palme <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Sender: [email-masked]

At 11.55 +0000 01-02-05, Charles Lindsey wrote:
>Yes, that is essentially the position I am coming from. HTML in news is to
>be severely discouraged (though not actually forbidden) just as binaries
>in news are severely discouraged. Again, hierarchies or groups explictly
>intended for binaries (or for HTML for that matter) are fine, so long as
>everybody agrees about them.
>
>The same is essentially true of email. It is not considered polite to send
>email in such forms unless you know that your correspondents is happy to
>receive it that way.
>
>So this still leave the question of how to send a digest (or other
>multipart) in either mail or news and to include with it some text
>explaining what it is about and including pointers to the individual
>digest items (whether in the form of a table of contents, or otherwise).
>
>That sounds like a useful thing to do, and it would seem that URLs
>identifying the items by their Content-ID is the proper way to do it, and
>the <cid: ...> URL seems to be the proper one for the job.

What you are doing is inventing a new mark-up language for
mail and news, in addition to the existing richtext and HTML
mark-up languages.

It seems silly to invent a new rich text format just because you
dislike HTML. Would it not be better, instead, to analyze the reasons
you dislike HTML, and specify a subset of HTML including restrictions
on where to use it, which satisfies your needs but avoids what you
dislike in HTML. If such a subset of HTML could be defined and avoids
your problems with HTML, it would allow reading software to use the
same code for interpreting full HTML and the subset you allow.
So only the producing software need to be rewritten to support
the new format.

If, for example, you dislike HTML because it is dificult to read
for those who read it as plain text, it might be possible to
define a way of using HTML to avoid this problem.

An example of such human-readable HTML coding is shown below:

--- --- ---

<p>   This is an example of HTML code, which is written
       so as to be readable for people who read it as
       plain text.

<p>   Here is the second paragraph, which contains a
          <a href="cid:[email-masked]"> link
</a>  to a separate body part.
<p>   Here is an embedded picture:

<p>      <img src="cid:[email-masked]" width="13" height="13">

<p>   End of this HTML-formatted message.

--- --- ---

Using such coding would eliminate the need for combining
HTML witch multipart/alternative, which today is commonly
done in order to produce messages readable for those, whose
readers do not support HTML. It would thus reduce the
larger size of messages needed to contain two alternatives
of the same text.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

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

In <p0501041ab6a0bd6bbc6f@[130.237.150.141]> Jacob Palme <[email-masked]> writes:

>Some readers of Charles Lindseys message may wonder why he
>asked for "cid:" support in plain text, why not HTML. The
>reason for this is, I believe, that HTML in messages is
>tremendously disliked by many people in the Usenet News
>community. They are planning to implement ways for a News-
>group to forbid HTML content.

Yes, that is essentially the position I am coming from. HTML in news is to
be severely discouraged (though not actually forbidden) just as binaries
in news are severely discouraged. Again, hierarchies or groups explictly
intended for binaries (or for HTML for that matter) are fine, so long as
everybody agrees about them.

The same is essentially true of email. It is not considered polite to send
email in such forms unless you know that your correspondents is happy to
receive it that way.

So this still leave the question of how to send a digest (or other
multipart) in either mail or news and to include with it some text
explaining what it is about and including pointers to the individual
digest items (whether in the form of a table of contents, or otherwise).

That sounds like a useful thing to do, and it would seem that URLs
identifying the items by their Content-ID is the proper way to do it, and
the <cid: ...> URL seems to be the proper one for the job.

But no current software seems to support it, judging by replies received
so far. So is it a case where an RFC is needed to set out the proper way
to do it (and should that cope with the general issue of URLs within
text/plain - which are widely implemented on an ad hoc basis at the
moment)?

I believe RFC 2110 has something to say on this issue, but I haven't
retrieved it yet.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131      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

From: Keith Moore <[email-masked]>
To: Jacob Palme <[email-masked]>
cc: [email-masked] (Charles Lindsey), [email-masked]
Subject: Re: The <cid: ...> URL - who implements it? 
Date: Fri, 02 Feb 2001 18:37:41 -0500
Sender: [email-masked]

> The reason why HTML in e-mail
> is so disliked by many Usenetters are:

(d) HTML that is generated by user agents is far uglier than it needs
to be.

however, I suspect that it's too late to fix this.  HTML in mail
and news already has a bad reputation that it's not likely to survive.

Keith

Date: Fri, 2 Feb 2001 20:40:19 +0100
To: [email-masked] (Charles Lindsey)
From: Jacob Palme <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Cc: [email-masked]
Sender: [email-masked]

Some readers of Charles Lindseys message may wonder why he
asked for "cid:" support in plain text, why not HTML. The
reason for this is, I believe, that HTML in messages is
tremendously disliked by many people in the Usenet News
community. They are planning to implement ways for a News-
group to forbid HTML content. The reason why HTML in e-mail
is so disliked by many Usenetters are:

(a) Many newsreaders do not support it, and the articles
     will then be very ugly.

(b) HTML in e-mail is much used by spammers, so it has
     become associated with something which is very much
     disliked and which is threatening Usenet News where
     some newsgroups get more spam than regular messages.

(c) News servers are always overloaded, and images is
     a major cause of this. HTML itself is not a major
     contributor to overload, but HTML tends to be com-
     bined with images, and the images are overloading
     news servers.

Note however, that avoding HTML in news by instead
including "cid:" URLs in plain text would not solve
the overload problem. An image is as large, whether
you refer to it from a plain text or a text/html
article.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Fri, 2 Feb 2001 20:39:36 +0100
To: [email-masked] (Charles Lindsey)
From: Jacob Palme <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Cc: [email-masked]
Sender: [email-masked]

At 10.34 +0000 01-02-02, Charles Lindsey wrote:
>RFC 2046 make provision for a Content-ID header in the parts of a
>multipart. RFC 2111 make provision for a <cid: ... > URL, which is
>apparently intended to allow one part of a multipart to include a
>reference to another part.
>
>So my question is: What systems, if any, currently support it, and exactly
>how is it intended to be used?

http://dsv.su.se/jpalme/ietf/mhtml.html#testprogs might give
some information on the implementation status. The following
mailers were tested:

Outlook Express Netsckape Messenger Eudoora Pine Hotmail Yahoo mail
KOM 2000 and Juno, and all of them could handle "cid:" URLs combined
with Content-ID on the image file.

The tests were only made for using "cid:" to refer to embedded
images in HTML-formatted messages, not for URLs referring to
content which is only shown when you click on the link, or
for URLs in plain text messages.
-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/

Date: Fri, 2 Feb 2001 10:48:02 -0600
To: Harald Alvestrand <[email-masked]>
From: Steve Dorner <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Cc: [email-masked] (Charles Lindsey), [email-masked]
Sender: [email-masked]

At 5:21 AM -0800 2/2/01, Harald Alvestrand wrote:
>the original reason for specifying the cid: URL was for use within 
>the context of HTML messages, where a "pointer to attached picture" 
>functionality was needed.
>
>I do not know if this is actually used by current HTML senders;

It is.

-- 
Sometimes he's nutty, sometimes he's corny...

Date: Fri, 02 Feb 2001 05:21:10 -0800
To: [email-masked] (Charles Lindsey), [email-masked]
From: Harald Alvestrand <[email-masked]>
Subject: Re: The <cid: ...> URL - who implements it?
Sender: [email-masked]

At 10:34 02/02/2001 +0000, Charles Lindsey wrote:
>RFC 2046 make provision for a Content-ID header in the parts of a
>multipart. RFC 2111 make provision for a <cid: ... > URL, which is
>apparently intended to allow one part of a multipart to include a
>reference to another part.
>
>So my question is: What systems, if any, currently support it, and exactly
>how is it intended to be used?

the original reason for specifying the cid: URL was for use within the 
context of HTML messages, where a "pointer to attached picture" 
functionality was needed.

I do not know if this is actually used by current HTML senders; I am sure 
there are people who can send some stuff in Outlook with pictures and look 
at the generated HTML....

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

To: [email-masked] (Charles Lindsey)
Cc: [email-masked]
Subject: Re: The <cid: ...> URL - who implements it?
From: Simon Josefsson <[email-masked]>
Date: 02 Feb 2001 14:02:50 +0100
Lines: 87
Sender: [email-masked]

[email-masked] (Charles Lindsey) writes:

> So my question is: What systems, if any, currently support it, and exactly
> how is it intended to be used?

A mailreader I use (Gnus) have some support for it, and once in a
while I do receive mail containing cid: links.

I don't recall any other use than having one main text/html part with
links to embedded pictures that are stored in other MIME parts of the
message.

> Contruct a multipart document (either multipart/mixed or
> multipart/digest). The first (introductory) part of it contains
> introductory material, including a Table Of Contents referring to the
> remaining parts (which themselves might be message/rfc822, or text/plain,
> or whatever else, each with its own Content-ID header).
> 
> The Table of Contents would include <cid: ... > URLs pointing to the
> individual parts. So is there any software out there that would support
> such a usage (e.g. by enabling you to click on the TOC entry so as to
> cause the corresponding part to be displayed)? And what Content-Type
> should the introductory part be? Text/plain, or something special?

text/plain with <URL:...> urls, or perhaps more reliable text/html
with <img src=...> or <a href=...> would work.

I'm not aware if any of the big clients would do something sensible
given such messages though.

> A possible application for this kind of thing would be FAQs published in
> newsgroups, but there are likely others.

Sending complete web pages (including images) via mail is the only use
I've seen yet.

> A related question is the general usage of URLs in text/plain material.
> Many reading agents try to detect these (usually pretty accurately, but
> with occasional mistakes) and to highlight them. Is this usage formally
> documented anywhere and, if not, should it be (perhape with supporting
> parameters in the Content-Type header)?

<URL:...> could be used inside plain text.  From RFC1738:

APPENDIX: Recommendations for URLs in Context

   URIs, including URLs, are intended to be transmitted through
   protocols which provide a context for their interpretation.

   In some cases, it will be necessary to distinguish URLs from other
   possible data structures in a syntactic structure. In this case, is
   recommended that URLs be preceeded with a prefix consisting of the
   characters "URL:". For example, this prefix may be used to
   distinguish URLs from other kinds of URIs.

   In addition, there are many occasions when URLs are included in other
   kinds of text; examples include electronic mail, USENET news
   messages, or printed on paper. In such cases, it is convenient to
   have a separate syntactic wrapper that delimits the URL and separates
   it from the rest of the text, and in particular from punctuation
   marks that might be mistaken for part of the URL. For this purpose,
   is recommended that angle brackets ("<" and ">"), along with the
   prefix "URL:", be used to delimit the boundaries of the URL.  This
   wrapper does not form part of the URL and should not be used in
   contexts in which delimiters are already specified.

   In the case where a fragment/anchor identifier is associated with a
   URL (following a "#"), the identifier would be placed within the
   brackets as well.

   In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
   need to be added to break long URLs across lines.  The whitespace
   should be ignored when extracting the URL.

   No whitespace should be introduced after a hyphen ("-") character.
   Because some typesetters and printers may (erroneously) introduce a
   hyphen at the end of line when breaking a line, the interpreter of a
   URL containing a line break immediately after a hyphen should ignore
   all unencoded whitespace around the line break, and should be aware
   that the hyphen may or may not actually be part of the URL.

   Examples:

      Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
      type=d> but you can probably pick it up from <URL:ftp://ds.in
      ternic.net/rfc>.  Note the warning in <URL:http://ds.internic.
      net/instructions/overview.html#WARNING>.

To: [email-masked]
Xref: clerew local.mime:535
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: The <cid: ...> URL - who implements it?
Date: Fri, 2 Feb 2001 10:34:35 GMT
Lines: 41
Sender: [email-masked]

RFC 2046 make provision for a Content-ID header in the parts of a
multipart. RFC 2111 make provision for a <cid: ... > URL, which is
apparently intended to allow one part of a multipart to include a
reference to another part.

So my question is: What systems, if any, currently support it, and exactly
how is it intended to be used?

To give an example of what I would like to do.

Contruct a multipart document (either multipart/mixed or
multipart/digest). The first (introductory) part of it contains
introductory material, including a Table Of Contents referring to the
remaining parts (which themselves might be message/rfc822, or text/plain,
or whatever else, each with its own Content-ID header).

The Table of Contents would include <cid: ... > URLs pointing to the
individual parts. So is there any software out there that would support
such a usage (e.g. by enabling you to click on the TOC entry so as to
cause the corresponding part to be displayed)? And what Content-Type
should the introductory part be? Text/plain, or something special?

A possible application for this kind of thing would be FAQs published in
newsgroups, but there are likely others.

A related question is the general usage of URLs in text/plain material.
Many reading agents try to detect these (usually pretty accurately, but
with occasional mistakes) and to highlight them. Is this usage formally
documented anywhere and, if not, should it be (perhape with supporting
parameters in the Content-Type header)?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131      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