Subject: Re: Default Dispositions
From: [email-masked] (Charles Lindsey)
To: [email-masked]
Date: Tue, 26 Oct 1999 20:26:50 GMT
Newsgroups: local.mime
List-Id: <ietf-822.imc.org>

In <[email-masked]> Charles Lindsey <[email-masked]> writes:

>Currently, there seem three schools of thought:

>1. You display the first part inline, and consider all the subsequent
>ones to be "attachments".

>2. You display all the parts inline, with some separator between them,
>such as a ruled line across the page.

>3. You display all the parts inline, with no visible separator. With
>care, you can even arrange to change parts within a single line (perhaps
>to intrpoduce a new character set or languauge) and have the result
>displayed seemlessly.

OK, let me sum up what seems to be the consensus of this list.

It seems that #1 is regarded as generally a bad idea. Text/plain parts
SHOULD be displayed inline unless the Content-Disposition indicates
otherwise.

As between #2 and #3, there is less agreement. It seems that to use #3 as
a means of changing charset/language in mid-line was never intended, and
there are better ways of doing it (use UTF-8, or some other form of
Unicode, and use the Unicode language-changung feature). Nevertheless, if
the user DOES choose to end the first part without any CRLF, then joining
the next part on without a break is clearly NOT WRONG (but that does not
necessarily make it RIGHT).

OTOH, several people have pointed out that some indication to the
recipient that a new part has been entered is often useful (for example,
the option to copy either part to a file on its own might still be a
useful feature to have.

At any rate, the purpose of my original question was to get help in
deciding what, if anything, the upcoming USEFOR draft on the News
protocols should say. We have a particular concern as to how signatures
should be treated, depending on whereabouts they may occur within the
various parts.

My inclination is that the draft should state that the preferred behaviour
for user agents is to show all text types inline by default (i.e. unless the
Content-Disposition indicated otherwise), but other types probably not
inline. We might even give this recommendation the strength of a SHOULD.

As to whether adjacent inline sections should be merged into one (as in
#3), I would probably leave that undefined. Or I might just say that
behaviour when a part did not end with CRLF might be different.
Eventually, the market will decide.

Does that all sound like a sensible interpretation of the discussion, and
a reasonable way forward for the News standard that will not adversely
affect future mail work?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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:252
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Default Dispositions
Date: Tue, 26 Oct 1999 20:10:19 GMT
Lines: 49
Sender: [email-masked]

In <[email-masked]> John C Klensin <[email-masked]> writes:

>But, Paul, you can't tell a "real attachment" from some other
>sort of body part in any fashion other than heuristically.
>"Content-type: text/plain" is a plausible heuristic, but there
>are many cases where that heuristic fails.  For example, if I
>wanted to attach (note that word creeping in) all of RFC 2046 to
>this message, I would hope that it would be treated as an
>attachment and displayed on request at the recipient end, not
>just folded into the text.

Sure, but I would expect you to declare Content-Disposition: file in that
case.

>Also, if a message arrives as 
>     text
>     image
>     image
>     text
>     text
>it is at least as likely, a priori, that the sender expected it
>to be displayed in exactly that order, or even with the images
>next to the first text part, as that 

I think I would expect all the parts to be displayed in order, with the
text portions inline (assuming the Content-Disposition did not say
otherwise) and with the images represented as icons, which you could click
on to see the pictures if you wished.
>> So when displaying a part we respect the sender's wishes, if
>> they don't put in a final line break then we don't either.

>Seems sensible.  How do you respect whatever wishes the sender
>was trying to express when she sent
>     text/plain
>     text/plain

Indeed. Presumably the sender had some intention in doing it that way. So
I would expect to see some indication (a separator line, or something).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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: Fri, 22 Oct 1999 09:29:42 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Default Dispositions
To: Paul Overell <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=klensin; server=shoe.reston.mci.net
Sender: [email-masked]

--On Friday, 22 October, 1999, 11:34 +0100 Paul Overell
<[email-masked]> wrote:

> Failing to display text/plain to the user just because it is
> not the first part seems perverse and unnecessarily
> restrictive.
> 
> It prevents having a series of "real attachments" interspersed
> with explanatory text.

But, Paul, you can't tell a "real attachment" from some other
sort of body part in any fashion other than heuristically.
"Content-type: text/plain" is a plausible heuristic, but there
are many cases where that heuristic fails.  For example, if I
wanted to attach (note that word creeping in) all of RFC 2046 to
this message, I would hope that it would be treated as an
attachment and displayed on request at the recipient end, not
just folded into the text.

Also, if a message arrives as 
     text
     image
     image
     text
     text
it is at least as likely, a priori, that the sender expected it
to be displayed in exactly that order, or even with the images
next to the first text part, as that 
   text
   text
   text
  (attachments)
   image
   image
or even
   text text text
  (attachments)
   image
   image
was expected.  Sometimes you'll be right, sometimes wrong --
just can't tell.

> So when displaying a part we respect the sender's wishes, if
> they don't put in a final line break then we don't either.

Seems sensible.  How do you respect whatever wishes the sender
was trying to express when she sent
     text/plain
     text/plain
rather than a single body part.  If something was implied by
that distinction (see example about attaching a large RFC,
above), then it seems you are ignoring that "wish" while
respecting the one that might have just been an error in
communication between the sending user and the composing agent/
sending MUA.

I'm not really suggesting that what you are doing is wrong, only
that this problem isn't easy, that users who really care should
probably be using Content-Disposition (and sending MUAs that
support it in a careful and intelligent way on a per-message
basis-- a set that I think is nearly null), and that any
implication of "X got it right and everyone else is wrong"
(which I note you did not say)  is probably a little excessive
in this context.

regards,
    john

Date: Fri, 22 Oct 1999 11:34:47 +0100
To: [email-masked]
From: Paul Overell <[email-masked]>
Subject: Re: Default Dispositions
Sender: [email-masked]

In article <[email-masked]>, Charles Lindsey
<[email-masked]> writes
>Currently, there seems no consensus on what you display when you receive a Mime 
>multipart where all the Content-Types are text (or other inline-able types) but 
>there are no Content-Dispositon headers to guide you. RFC 2183 is silent as 
>regards a defaults for Content-Dispositon.
>
>Currently, there seem three schools of thought:
>
>1. You display the first part inline, and consider all the subsequent
>ones to be "attachments".
>

Failing to display text/plain to the user just because it is not the
first part seems perverse and unnecessarily restrictive.

It prevents having a series of "real attachments" interspersed with
explanatory text.

It causes problems such as personal signatures not being displayed just
because the sender placed it, naturally enough, at the end of the
message - after a real attachment. 

>2. You display all the parts inline, with some separator between them,
>such as a ruled line across the page.
>
>3. You display all the parts inline, with no visible separator. With
>care, you can even arrange to change parts within a single line (perhaps
>to intrpoduce a new character set or languauge) and have the result
>displayed seemlessly.
>

We implemented 3 rather than 2 because in RFC2046 p20 it says:

>NOTE:  The CRLF preceding the boundary delimiter line is conceptually
>attached to the boundary so that it is possible to have a part that
>does not end with a CRLF (line  break).  

So when displaying a part we respect the sender's wishes, if they don't
put in a final line break then we don't either.

>AFAIK, the only agent to provide #3 is Turnpike, and they seem to be
>especially proud of their achievement :-).
>

We believed (and believe) that we were simply following the
specification, both in spirit and letter.

Regards
-- 
Paul Overell                                        T U R N P I K E  Ltd

From: "Mariano Absatz" <[email-masked]>
To: John C Klensin <[email-masked]>
Date: Thu, 21 Oct 1999 16:27:23 -0300
Subject: Re: Default Dispositions
CC: Lista IETF - RFC-822 <[email-masked]>
Sender: [email-masked]

I agree with you, John... besides I already have proof of misuses of this 
kind of thing when totally unnecesary.

It seems there is some version (or configuration or something) of Lotus 
Notes' SMTP gateway that does the following:
When it gets a Notes mail to relay to Internet (SMTP/MIME world) it 
assumes it's 7bit USASCII, if later on it realizes there is an accented 
character, it generates a second part of a multipart message with contat-
disposition: inline where the second part is quoted-printable (or 8bit) 
iso-8859-1.

Note that USASCII is a proper subset of ISO-8859-1 and I think it's clear 
for any reader of any version of the MIME specification that what should 
be done here is use a single part with quoted-printable iso-8859-1. 
Result: since content-disposition is not part of the basic MIME 
compliance requirement there are lots of MIME readers that don't 
understand this (#3) and you end up seeing an awful #1 or #2 splitted in 
the middle of a word.

I would vote for either #1 or #2 going as default just to discourage its 
misuse (and would like to see a comment in the RFC stating: "don't use it 
for this kind of thing since you should'n").

El 19 Oct 99, a las 10:29, John C Klensin escribió:

> --On Tuesday, 19 October, 1999, 08:46 +0000 Charles Lindsey
> <[email-masked]> wrote:
> 
> > >Option #3 seems like the most reasonable interpretation to
> > me.  If you have >a multipart/mixed, and a part doesn't have a
> > content-disposition, it makes >the most sense to me to display
> > the part inline if you can and as an >attachment if you can't.
> > 
> > I am surprised (but a couple of other responses that have not
> > reached the list yet also support that view).
> > 
> > My chief concern with #3 is that the reader get no indication
> > that the message was a multipart. He just sees the texts
> > following on with no apparent break (even on the same line, if
> > the author was careful to arrange it that way). Are you happy
> > with that?
> 
> My initial impression was "silly", for just that reason, but
> don't have time right now to compose an in-depth explanation.
> The only strong argument I can think of for it is that it would
> force a lot more use of content-disposition, which may or may
> not be desireable.  The notion of using multiparts to represent
> different charsets/ languages into a single message flow was
> discussed during the MIME development process and rejected ---
> that sort of thing really needs to be done by markup, not
> multipart structures and the hope that the receiving MUA will do
> something very specific.
> 
>     john
> 

--
Mariano Absatz - El Baby
mailto:[email-masked]
http://www.baby.com.ar/
    PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp
  |\  _
  _\\/'>     Powered by Pegasus Mail
 /|__)       http://www.pmail.com
  ) )\
-----------------------------------------------------------
If at first you don't succeed, call it version 1.0 

Date: Wed, 20 Oct 1999 13:45:19 -0500 (CDT)
From: Rick Troth <[email-masked]>
To: [email-masked]
Subject: RE: html and active content. 
Sender: [email-masked]

	I like the distinction.   It gives us a handle on the 
anticipated impact.   I don't see it as a trust thing,  but as a 
performance thing.   Still need the sandbox either way,  but we 
have a hint as to how much fuel the engine will burn.   That helps. 
 
	I'm seeing this in a lot of web pages.   There too, 
we should distinguish between "active" and "static".   And frankly, 
active sucks processor power,  often wastefully.   Labelling helps. 

-- 
Rick Troth at La Casita, Houston, Texas, USA 

To: "Jeff Stephenson (Exchange)" <[email-masked]>
Cc: [email-masked]
Subject: Re: html and active content. 
From: [email-masked]
Date: Wed, 20 Oct 1999 12:00:05 -0400
Sender: [email-masked]

--==_Exmh_-2139488680P
Content-Type: text/plain; charset=us-ascii

On Wed, 20 Oct 1999 08:29:36 PDT, "Jeff Stephenson (Exchange)" <[email-masked]>  said:
> between text/html and application/html.  I'm certainly not going to forgo a
> sandbox just because the (possibly malicious) sender says "trust me - this
> is static content".  Since there would be no change in behavior, I don't see
> why a distinction would be useful.

The distinction is useful in that if it says up front "I have active content",
I can say "forget this, I'm not launching an HTML viewer" and skip all the
resource expense of finding out that it is/isnt static content.

Would there be more support for a parameter on the text/html, specifying
what active features, if any, were included?

Note that I am *NOT* denying that the HTML viewer will need to be sandboxed.
What I want is a way up front for the HTML to say "I will try to do at least
THIS much, don't bother if you're not willing".  Note that this *DOES* have
implications for display for a multipart/alternative - I've gotten more than
one piece of mail that had both text/html and text/plain, where the HTML
was chosen but was then failed by the HTML viewer - if it had been tagged
correctly, my MUA could have gone straight to text/plain.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-2139488680P
Content-Type: application/pgp-signature

--==_Exmh_-2139488680P--

From: "Jeff Stephenson (Exchange)" <[email-masked]>
To: [email-masked]
Subject: RE: html and active content. 
Date: Wed, 20 Oct 1999 08:29:36 -0700
Sender: [email-masked]

> a) too widely deployed, too late to change
> b) nobody is going to bother scanning .HTM files to see whether
>    they have active content
> c) the recipient needs the sandbox in both cases anyway
> 
> Keith

I think all Keith's comments are relevant, but especially (c): I just don't
see how the receiving MUA would change its behavior based on the difference
between text/html and application/html.  I'm certainly not going to forgo a
sandbox just because the (possibly malicious) sender says "trust me - this
is static content".  Since there would be no change in behavior, I don't see
why a distinction would be useful.

-- jeff

Date: Wed, 20 Oct 1999 14:09:03 +0200
From: Daniel Glazman <[email-masked]>
Organization: EDF - DER
To: [email-masked]
CC: [email-masked]
Subject: Re: html and active content.
Sender: [email-masked]

[email-masked] wrote:

> We have seen a number of attacks via e-mail that use text/html to carry
> pointers to malicious code.  We also had, many moons ago, a small war regarding
> text/html versus application/html.
> 
> I propose the following straw man:
> 
> text/html be redefined such that it contains static content only.
> application/html be redefined such that active content such as Javascript
> be allowed.

Hum.

What if the document does not contain directly script but has a LINK
to a js file ? If it contains a link to an applet ?
And if the document is the result of a CGI ?

</Daniel>

From: Keith Moore <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: html and active content. 
Date: Tue, 19 Oct 1999 22:12:26 -0400
Sender: [email-masked]

> text/html be redefined such that it contains static content only.
> application/html be redefined such that active content such as Javascript
> be allowed.

a) too widely deployed, too late to change
b) nobody is going to bother scanning .HTM files to see whether
   they have active content
c) the recipient needs the sandbox in both cases anyway

Keith

To: [email-masked]
Subject: html and active content.
From: [email-masked]
Date: Tue, 19 Oct 1999 10:49:15 -0400
Sender: [email-masked]

--==_Exmh_-1045345710P
Content-Type: text/plain; charset=us-ascii

We have seen a number of attacks via e-mail that use text/html to carry
pointers to malicious code.  We also had, many moons ago, a small war regarding
text/html versus application/html.

I propose the following straw man:

text/html be redefined such that it contains static content only.
application/html be redefined such that active content such as Javascript
be allowed.

This would allow MUAs that can parse html to employ whatever "sandbox"
techniques it wanted to on text/html, and more importantly, for the SENDING
MUA to be able to flag the intent - if the sender knows it's only static
content (using text/html as a text/enriched, for example), the sender will
know what restrictions will be placed at display time.

Conversely, if there IS active code, the sending MUA can flag this, and
be prepared to be sandboxed if the recipient wishes to do so.

There would probably have to be a restriction for the text/html variant on
what references would be acceptable on an embedded URL - possibly restricting
it to multipart/related with the same message-id:, so that you can't induce
a reference to a malicious webserver.

OK, there's a straw man.  Get your matches out. ;)
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1045345710P
Content-Type: application/pgp-signature

--==_Exmh_-1045345710P--

To: [email-masked] (Charles Lindsey)
Cc: [email-masked]
Subject: Re: Default Dispositions 
From: [email-masked]
Date: Tue, 19 Oct 1999 10:40:17 -0400
Sender: [email-masked]

--==_Exmh_-1060454304P
Content-Type: text/plain; charset=us-ascii

On Tue, 19 Oct 1999 08:46:34 GMT, [email-masked] (Charles Lindsey)  said:
> My chief concern with #3 is that the reader get no indication that the
> message was a multipart. He just sees the texts following on with no
> apparent break (even on the same line, if the author was careful to arrange
> it that way). Are you happy with that?

Actually, option #3 strikes me as incredibly neat.  However, I *do* fear
the consequences of a "reply with text" or other citing mechanism, as the
usual '> ' will *totally* mangle the entire thing, leaving pure zorkumblattum.

Fortunately, the two main uses for this "feature" that I can think of are:

1) Changing charsets on the fly - this would probably be better addressed
by sending *one* bodypart with a UTF-8 charset.  Anybody disagree on that?

2) Embedding a small image/button/etc - this is better addressed with a
text/html and multipart/related.

Anybody think of anything I've missed?

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_-1060454304P
Content-Type: application/pgp-signature

--==_Exmh_-1060454304P--

Date: Tue, 19 Oct 1999 10:29:40 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Default Dispositions
To: Charles Lindsey <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=klensin; server=shoe.reston.mci.net
Sender: [email-masked]

--On Tuesday, 19 October, 1999, 08:46 +0000 Charles Lindsey
<[email-masked]> wrote:

> >Option #3 seems like the most reasonable interpretation to
> me.  If you have >a multipart/mixed, and a part doesn't have a
> content-disposition, it makes >the most sense to me to display
> the part inline if you can and as an >attachment if you can't.
> 
> I am surprised (but a couple of other responses that have not
> reached the list yet also support that view).
> 
> My chief concern with #3 is that the reader get no indication
> that the message was a multipart. He just sees the texts
> following on with no apparent break (even on the same line, if
> the author was careful to arrange it that way). Are you happy
> with that?

My initial impression was "silly", for just that reason, but
don't have time right now to compose an in-depth explanation.
The only strong argument I can think of for it is that it would
force a lot more use of content-disposition, which may or may
not be desireable.  The notion of using multiparts to represent
different charsets/ languages into a single message flow was
discussed during the MIME development process and rejected ---
that sort of thing really needs to be done by markup, not
multipart structures and the hope that the receiving MUA will do
something very specific.

    john

To: [email-masked]
Xref: clerew local.mime:240
Newsgroups: local.mime
Path: clerew!chl
From: [email-masked] (Charles Lindsey)
Subject: Re: Default Dispositions
Date: Tue, 19 Oct 1999 08:46:34 GMT
Lines: 34
Sender: [email-masked]

In <[email-masked]> Dan Crevier <[email-masked]> writes:

>On 10/18/99 8:53 AM, Charles Lindsey wrote:

>> 3. You display all the parts inline, with no visible separator. With
>> care, you can even arrange to change parts within a single line (perhaps
>> to intrpoduce a new character set or languauge) and have the result
>> displayed seemlessly.
>> 

>Option #3 seems like the most reasonable interpretation to me.  If you have
>a multipart/mixed, and a part doesn't have a content-disposition, it makes
>the most sense to me to display the part inline if you can and as an
>attachment if you can't.

I am surprised (but a couple of other responses that have not reached the
list yet also support that view).

My chief concern with #3 is that the reader get no indication that the
message was a multipart. He just sees the texts following on with no
apparent break (even on the same line, if the author was careful to arrange
it that way). Are you happy with that?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     [email-masked]  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      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: Mon, 18 Oct 1999 10:32:21 -0700
Subject: Re: Default Dispositions
From: Dan Crevier <[email-masked]>
To: Charles Lindsey <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On 10/18/99 8:53 AM, Charles Lindsey wrote:

> Currently, there seems no consensus on what you display when you receive a
> Mime 
> multipart where all the Content-Types are text (or other inline-able types)
> but 
> there are no Content-Dispositon headers to guide you. RFC 2183 is silent as
> regards a defaults for Content-Dispositon.
> 
> Currently, there seem three schools of thought:
> 
> 1. You display the first part inline, and consider all the subsequent
> ones to be "attachments".
> 
> 2. You display all the parts inline, with some separator between them,
> such as a ruled line across the page.
> 
> 3. You display all the parts inline, with no visible separator. With
> care, you can even arrange to change parts within a single line (perhaps
> to intrpoduce a new character set or languauge) and have the result
> displayed seemlessly.
> 
> AFAIK, the only agent to provide #3 is Turnpike, and they seem to be
> especially proud of their achievement :-).

Claris Emailer and Microsoft Outlook Express for the Macintosh both provide
#3.

> Note that all 3 possibilities are perfectly legal, which is a problem
> because people can then write messages/articles not knowing how they are
> gpoing to be presented at the far end. Life gets even more complicated
> when you consider what is the correct way to generate a followup to such
> an article or message, and what you do with any signatures that may be
> included within any of the parts.
> 
> So my question is: What do people on this list feel is the "correct", or
> the "intended" or the "best" interpretation?
> 
> The question arises because we are writing the relevant pieces of text
> for the draft-grandson-of-1036, and we are considering whether to say
> anything firm on this issue. But if we do so, we would like to hear the
> opinion of the email gurus first, since it would be a pity if news and
> email were to diverge signficiantly on this issue.

Option #3 seems like the most reasonable interpretation to me.  If you have
a multipart/mixed, and a part doesn't have a content-disposition, it makes
the most sense to me to display the part inline if you can and as an
attachment if you can't.

Dan

-- 
Dan Crevier <[email-masked]>
Microsoft Outlook Express Developer

Date: Mon, 18 Oct 1999 16:53:44 +0100 (BST)
From: Charles Lindsey <[email-masked]>
Reply-To: Charles Lindsey <[email-masked]>
Subject: Default Dispositions
To: [email-masked]
Content-MD5: hifm4xHCe+kjJhym6ZF2aA==
Sender: [email-masked]

Currently, there seems no consensus on what you display when you receive a Mime 
multipart where all the Content-Types are text (or other inline-able types) but 
there are no Content-Dispositon headers to guide you. RFC 2183 is silent as 
regards a defaults for Content-Dispositon.

Currently, there seem three schools of thought:

1. You display the first part inline, and consider all the subsequent
ones to be "attachments".

2. You display all the parts inline, with some separator between them,
such as a ruled line across the page.

3. You display all the parts inline, with no visible separator. With
care, you can even arrange to change parts within a single line (perhaps
to intrpoduce a new character set or languauge) and have the result
displayed seemlessly.

AFAIK, the only agent to provide #3 is Turnpike, and they seem to be
especially proud of their achievement :-).

Note that all 3 possibilities are perfectly legal, which is a problem
because people can then write messages/articles not knowing how they are
gpoing to be presented at the far end. Life gets even more complicated
when you consider what is the correct way to generate a followup to such
an article or message, and what you do with any signatures that may be
included within any of the parts.

So my question is: What do people on this list feel is the "correct", or
the "intended" or the "best" interpretation?

The question arises because we are writing the relevant pieces of text
for the draft-grandson-of-1036, and we are considering whether to say
anything firm on this issue. But if we do so, we would like to hear the
opinion of the email gurus first, since it would be a pity if news and
email were to diverge signficiantly on this issue.

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