home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
receipt
/
receipt-minutes-96jun.txt
< prev
next >
Wrap
Text File
|
1996-10-04
|
4KB
|
96 lines
Editor's Note: These minutes have not been edited.
Here are the draft minutes of the RECEIPT working group. Comments
are welcome and I'll produce updated minutes if required. Deadline for
comments is July 5th, for the minutes July 12th. Many thanks to all who
attended the meeting. It was fun working with you. And it's good to see
concrete and useful results coming out.
Keep up the good work,
Urs.
-----------------------------------------------------------------------------
Draft Minutes for Receipt IETF Working Group
Co-Chairs: Urs Eppenberger <eppenberger@switch.ch>,
Ned Freed <ned@innosoft.com>
Minutes: Chris Newman <chris.newman@innosoft.com>
1. Open issues
--------------
1) Type for reporting user agent removed. Other types left in. (See Sec
3.1.2) Discussed at last IETF.
2) Question about the comparison between the address & Return-Path
for disposition notification. What if no Return-Path header? Counts as
a failure of the comparison. Strip source routes for comparison. What if
multiple Return-Path headers? Could pick the first one. Is a protocol
error, so can failure the comparison. Document editor will work out
wording.
There was also a suggestion on the list that multiple addresses be
allowed in Disposition-Notification-To. Add text explaining why
multiple addresses is a bad idea. Don't want to disallow it. Add more
discussion about why automatic replies are dangerous in these cases.
Document editor will work out wording.
3) List of dispositions. Added automatic dispositions. Distinction
between generated by UA, and generated by user. Proposal:
acknowledged (user-acknowledge) disposition which means the user
has taken action to acknowledge the receipt of this message. The
problem is that "displayed" could be automatically generated by UI.
Alternative: a separate "manual-user-acknowledged" attribute and
drop the "auto-*" dispositions. What if secretary responds for boss?
Add a comment about using Sender/From distinction for human agents?
No. Let drums document make the distinction. Just reference 822 for
details on generating from/sender. (Section 3.2.6)
Eliminate "denied"? "denied" is a way to say "you shouldn't have sent
me this". This is useful, so we'll keep it.
4) Discussion about mailing list support and list recipients (3.2.7). There
is a requirement by some U.S. government agencies to get a list of all
recipients of a message -- is this a good mechanism? Don't try to solve
this now. Is this mechanism proper for this draft? Defer for further
study? Yes, this is a rat hole.
2. Work left for the I-D
------------------------
Jim Galvin (?) will produce more text for the security section Keith
Moore will work on the Mailing list section and either approve the
current text or provide better wording. All new text and additional
comments have to be sent to the mailing list by July 15th.
Roger Fajman will update the I-D by end of July.
3. Usage of RECEIPT work for EDI
--------------------------------
It has been discussed how the prposed receipts can be used by the
EDIINT working group. Their requirements are signed receipts. It has
been accepted to extend the I-D if needed by EDIINT. (Later discussions
after the meeting showed, that they will most probably define a new
notification type signed-receipt and therefore will use the NOTARY
framework but be independent of NOTARY.)
4. Other extensions
-------------------
Perhaps we should add parameters to disposition-notification?
Concensus that we need parameters. One header or two headers? A sub-
group will make a solid proposal by July 15th. Ned Freed will work on
it.
5. Other work related to RECEIPT
--------------------------------
Vacation- / Change of address - notifications
The group decided, that these are not receipts. A data format might be
needed to support automated handling. The tasks are not close enough
to the current charter of the working group to justify inclusion. If
someone wants it bad enough, he can come up with a proposal and
publish it as an I-D and get a working group started on it.