Message-Id: <3.0.32.19961220134324.00e50c64@lacroix>
Date: Fri, 20 Dec 1996 13:43:25 -0500
To: "D. J. Bernstein" <djb@koobera.math.uic.edu>, drums@cs.utk.edu
From: "Jack De Winter" <jack@wildbear.on.ca>
Subject: Re: blank line as head/body separator
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Comment: No Mime-content-encoding found in headers (although mime headers used),
 Content-Transfer-Encoding header added by lacroix.wildbear.on.ca (SLMailNT V3.0)

At 08:14 AM 12/20/96 -0000, D. J. Bernstein wrote:
>> I do not agree that ALL invisible continuations MUST be interpreted as per
>> 822.
>
>This doesn't mean that parsers actually have to use that algorithm!
>
>Most importantly, when the algorithm barfs, a parser can accept the
>message anyway. This is a quality-of-implementation issue.

I don't fully agree with this.  However, if we agree that these individual
contiuation lines (i.e. a line with WS*WS CR LF instead of a blank line)
are going to crop up, I would like to see a list in the specification
of all of the possibilities and how they impact the user.

The most annoying thing with the implementation of 821 (the companion
to the 822bis we are discussing), was all of the arbitrary 'changes'
that were made by implementors.  I go to put in proper quoting rules
and half the people say to use 821 rules and half say to use 822 rules.
I still don't have a good answer on which I should be using and how to
deal with messages in the 821 quoting rules...

We are trying to interoperate.  Trying to interoperate without knowing
what little things people have relaxed on some of their systems, what
practices people have changed, etc., makes it very difficult for people
to implement.  I have forwarded to John Klensin a small list of some
of the relaxations that are common.

The problem with some of these relaxations and changes not being
incorporated into the 821bis and 822bis is that people do not know
about them.  For example, we were told that we were a really bad 
and totally useless implementation of SMTP because we did not do
the same implementation of VRFY as someone else (the one in question
actually tried to spawn a VRFY on the destination system).

>> Even there, I would want to at
>> least give a warning to implementors that some messages which might look
>> conformant might not have been intended as they would normally be
>> interpreted.
>
>Whenever we assign meaning to something, it _might_ be true that the
>sender's desired meaning is something else.
>
>That doesn't mean we should be wishy-washy about the assignment.
>
>This is true even when the behavior is prohibited. We assign meaning to
>EST even though someone who uses EST _might_ mean Estonia Standard Time.

This is a good point.  On the time zones though, I think as a group
we are starting to move away from the alphanumeric zones and to the
purely numeric zones.

>> You seem to bring this up every so often.
>
>Hmmm? How often is that?
>
>It seems quite relevant here. Eudora's excuse for misinterpreting
>invisible continuation lines---namely, they _might_ be separators---
>doesn't apply to messages that do have blank lines. This eliminates the
>entire compatibility problem, given Eudora's assumptions about
>separators.

There are valid points from both sides.  From Dan's side he wants to see
things following the specification.  From Pete's (or was it Randy's) side,
they want to give the messages a choice, otherwise it may appear to the
user that they do not handle certain situations properly.  One is a
theological argument and one is a presentation argument.

>> Is this relavent?
>
>Yes, it's relevant. Certain people are making the same mistakes now.

I think some of Dan's viewpoint may be that instead of actually
accomodating people who seem to think that blank lines are okay,
we should try and get them to fix their systems.  Eudora's angle on
this would be to accomodate as it might be hard to get them to fix
their implementations.

There are two perfectly valid points here (as I point out to a class
I teach, two diametric viewpoints can be totally correct).  Is there
any way that we can resolve these issues between both camps and come
to something that everyone can live with?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.