headers
David Robinson | 1 May 1991 15:56

re: Please don't dump version numbers.

I think that the issue is not whether version numbers (and other attributes)
should exist, but where to put them.  PostScript offers us a good example.
After much thrashing about in the very early days, they began including the
version information in the actual contents of the PS object.  

This is good practice.  It ensures that the version (and other attributes)
stay associated with the object.  Of course, this also requires some simliar
consideration by the designers of objects as well as by those trying to
figure out how to convert the objects to and from mailable body parts.

Yes, it is always true that you could come up with a new version which is
totally incompatible with the previous version.  If so, then I would say that
your new version really needs another encoding type - it isnt FOO anymore,
but FOO-2.0.

-David
Permalink | Reply | 0 comments |
headers
MMDF Mail Administrator | 1 May 1991 19:01
Picon

Re: Please: a solution to help the most people

> I agree with this, except I believe that we need to take it further.  
> Borrowing from X.400, what I believe is needed is the ability to request
> both return receipts (when the message is actually read) as well as
> delivery notifications (when the message is placed in the recipients
> mailbox).  I'm not sure that I completely agree with X.400 however in
> that the user has the capability to do this on a per-recipient basis.
> Perhaps, a single request that applies to all recipients would be
> adequate.

Speaking as a member of a support group for a large number of users
that currently have the Return-Receipt-To: capability I can comment on
a few things:

1)  They like it and believe that they cannot live without it.

2)  The ability to request it on a per recipient basis is very often
    requested.

3)  The ability to get a receipt when the message is read starts religious
    wars both in NCR and in the news discussions I have followed.

> Needless to say, this is a religous issue.  My personal
> stand is the same as stated in X.400 (88):

I think that I agree with this.  The ability to request an indication
that a message has been deposited in a recipients mailbox should be
at the discretion of the sender.  Any indication of whether or not that
message has actually been read should be at the discretion of the recipient.

Possibly more to the point here is whether the mechanism should be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Crispin | 1 May 1991 20:23

return receipts

There's a problem with the concept.

It may be OK to provide return receipts (whether to a mailbox or if the user
actually read the message) within the confines of a single organization.

But as soon as you leave those confines, things are different.

There are many people out there, such as me, who are guaranteed to sabotage
any return receipt mechanism they find in a mailer on any system they use.
The problem is, there are at times messages that I do *not* want to
acknowledge in any way.
Permalink | Reply | 2 comments |
headers
tep | 1 May 1991 22:03

return receipts

   Date: Wed, 1 May 1991 11:23:45 -0700 (PDT)
   From: Mark Crispin <akbar.cac.washington.edu!mrc <at> ucsd.EDU>

   There's a problem with the concept.

   It may be OK to provide return receipts (whether to a mailbox or if the user
   actually read the message) within the confines of a single organization.

   But as soon as you leave those confines, things are different.

   There are many people out there, such as me, who are guaranteed to sabotage
   any return receipt mechanism they find in a mailer on any system they use.
   The problem is, there are at times messages that I do *not* want to
   acknowledge in any way.

I understand your concern about return-receipts; I am also concerned
about privacy.

I prefer the Multics approach: Give the recpient the *choice* of
whether or not to supply the receipt.

My preferred approach is to allow for the transport of the reciept
*request*, and make the generation of the receipt a UA function, with
appropriate user controls to enable/disable the generation of the
receipt when the message is read/displayed/whatever.

Its like Caller-ID. There are ways to guarantee the privacy of the
sender and recipient both.

Tom Perrine (tep)                       |Internet: tep <at> tots.Logicon.COM
(Continue reading)

Permalink | Reply | 1 comment |
headers
Neil Rickert | 1 May 1991 23:17
Favicon

Re: return receipts

In article <9105012003.AA01187 <at> tots.Logicon.COM> tep <at> tots.logicon.com writes:
>
>My preferred approach is to allow for the transport of the reciept
>*request*, and make the generation of the receipt a UA function, with
>appropriate user controls to enable/disable the generation of the
>receipt when the message is read/displayed/whatever.

 The only return receipt I believe is the one voluntarily created by the
intended recipient and commenting on the contents of the message.  And as
soon as you automate that I will stop believing it too.

--

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert <at> cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940
Permalink | Reply | 0 comments |
headers
Einar Stefferud | 1 May 1991 23:18
Picon

POINT OF ORDER AGAIN! (Re: Please: a solution to help the most people)

Gentlepeople, All!  This is not a TRANSPORT (RFC821 SMTP) topic.

It belongs on the IETF-822 list where we are workingon HEADER like
this!

I will agree that it is a relavant topic for ietf-822, but lets
discuss it there.

Mr. Chairman -- Can you please make another ruling on this?

Best...\Stef
Permalink | Reply | 0 comments |
headers
Bob | 2 May 1991 02:49
Picon
Picon

Conversion and character set proposals worry me

1) I was on the side of allowing MTAs to change transport encoding. We
seem to have settled on the conservative position that this should
only take place in MTAs in carefully controlled circumstances. We
now have suggestions floating about that MTAs may change the underlying
decoded bits of a message to make it comply with 10646. Given the
earlier decision I find this incredible. I certainly don't agree with
it. The argument that these are "gateways" within the Internet does
not impress me. Even gateways should change as little as possible and
I would need a lot of convincing to believe that this sort of change
is really necessary.

To me MTAs should (on behalf of nearby UAs): (a) add Content headers; 
(b) Change transport encoding if necessary.

If the MTA is not going to change the bits in the message it has to be
able to specify a Content-type for the character sets in actual current use.

------------------------------------------------------------------------

2) In the current 7-bit style the meaning depends on off-line agreement 
between sender and receiver. It has been suggested that this "TEXT"
format works fine in practise. I disagree.

Consider something we've all seen:

>	From: Keld J|rn Simonsen <keld <at> dkuug.dk>

The fact is that we don't see what the originator meant us to see. We
see a vertical bar where we are meant to see an "o" with a "/" through
it. This is a very small break down in communication. We could look
(Continue reading)

Permalink | Reply | 0 comments |
headers
The TallyMan | 2 May 1991 15:43
Picon

Return Receipts -- POINT OF ORDER


Stef, Tim, Bob, Mark (Crispin),

	My appologies for the slow response to the questions of where
this return receipt discussion go.  The question was posed in such a
way that is appears that someone wants me to decide where the return
receipt discussion belongs, and by doing so, limit the scope of the
solution.  Let me answer in the following fashion.

	There is a lot more mail related work to do in these groups.
Currently we are working on a message format document for multi-media,
and multi-type mail, and a documents on how to transport 7 and 8 bit
data.   In the future we outlined some other efforts worth doing
including defining a SMTP (or general mailer) MIB, a standard error
reporting format for failed mail messages, and possible a series of
gateway requirements documents.  Return receipts are another issue we
can deal with.

	At this time, I encourage you to take this discussion
off-line.  If you reach a consensus I encourage you to write a draft
rfc document discussing the issues and specifying a protocol.  The
list would be interested in seeing any such document.  If consensus is
not reached, I would gladly take up this issue again, when  we finish
with the major work on the multi-media, multi-part document.

Questions?

Greg Vaudreuil

IETF Mail Extensions working group(s) chair.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David_Thompson%GN%7cg | 7 May 1991 11:58

Re: lines, SMTP, ...


Please-reply: thompson

     What is the generally accepted message body format for
line length restrictions ?  Is there a standard on this (ala RFC 822),
or is it by generally accepted convention ?  I have been told by my
network support shop that 80 characters is the "unspoken"
standard [including CRLF] and that the RFC's dont mention it
anywhere.  I have a platform that generally line-wraps without
using CRLF structure.  When this mail is sent over the mail-relay
gateway, the message body is not reformatted.  Thus, when other
platforms on our InterNet receive this mail, the receiving software
does not handle the message body very gracefully, if at all.  It has
raised a lively internal debate whether the sending side or the
receiving side needs to have its software modified.  We have
been using RFC 821 and RFC 822 in our organization as standards
to request conformance with SMTP as the common denominator
among dissimilar and proprietary systems.  The issue of the message
body format itself, how it is created and how it is displayed remain
unresolved issues.  Please respond.  Thank you.
     -- David Thompson
Permalink | Reply | 0 comments |
headers
Einar Stefferud | 10 May 1991 06:58
Picon

Re: lines, SMTP, ...

Hello David -- Since I see no other relies as yet, I will take a shot
at your question.

First, if you read RFC821/822 very very carefully, you will see that,
no matter how you might represent locally lines in your internal files
in your UA, when you put the text on the line with SMTP, it must have
each line ended with a <CRLF> and nothing else.  If the eceiving end
does not like this "transfer syntax" for its own local store
conventions, then it is obligated to translate the

	<end-of-line--new-line>

encoding to be what it wants internally.

This is one of the many protocol rules that make things interwork
between dissimilar systems.  The entire interworing agreement rests on
the ability for everyone to always put these objects "on the wire"
with the same syntax so it can be unambiguously decoded by the
receiving systems.

Also, SMTP requires that lines must be less than 1000 characters long,
but common courtesy suggests (not written in the standards) that you
make them less than 80 characters in order for them to "look nice" on
all recipient display screens.  Many systems and terminals fold lines
after the 79th character on the line.

If you don't care what your text looks like on my 79 character
display, then go ahead and make your lines 80 or 81 or whatever number
of characters long you might wish.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane