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 >
Text File  |  1996-10-04  |  4KB  |  96 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. Here are the draft minutes of the RECEIPT working group. Comments 
  5. are welcome and I'll produce updated minutes if required. Deadline for 
  6. comments is July 5th, for the minutes July 12th. Many thanks to all who 
  7. attended the meeting. It was fun working with you. And it's good to see 
  8. concrete and useful results coming out. 
  9.  
  10. Keep up the good work,
  11.  
  12. Urs.
  13. ----------------------------------------------------------------------------- 
  14.  
  15. Draft Minutes for Receipt IETF Working Group 
  16.  
  17. Co-Chairs: Urs Eppenberger <eppenberger@switch.ch>, 
  18. Ned Freed <ned@innosoft.com>
  19. Minutes: Chris Newman <chris.newman@innosoft.com> 
  20.  
  21. 1. Open issues
  22. --------------
  23. 1) Type for reporting user agent removed. Other types left in. (See Sec 
  24. 3.1.2) Discussed at last IETF.
  25.  
  26. 2) Question about the comparison between the address & Return-Path 
  27. for disposition notification. What if no Return-Path header? Counts as 
  28. a failure of the comparison. Strip source routes for comparison. What if 
  29. multiple Return-Path headers? Could pick the first one. Is a protocol 
  30. error, so can failure the comparison. Document editor will work out 
  31. wording.
  32.  
  33. There was also a suggestion on the list that multiple addresses be 
  34. allowed in Disposition-Notification-To. Add text explaining why 
  35. multiple addresses is a bad idea. Don't want to disallow it. Add more 
  36. discussion about why automatic replies are dangerous in these cases. 
  37. Document editor will work out wording. 
  38.  
  39. 3) List of dispositions. Added automatic dispositions. Distinction 
  40. between generated by UA, and generated by user. Proposal: 
  41. acknowledged (user-acknowledge) disposition which means the user 
  42. has taken action to acknowledge the receipt of this message. The 
  43. problem is that "displayed" could be automatically generated by UI. 
  44. Alternative: a separate "manual-user-acknowledged" attribute and 
  45. drop the "auto-*" dispositions. What if secretary responds for boss? 
  46. Add a comment about using Sender/From distinction for human agents? 
  47. No. Let drums document make the distinction. Just reference 822 for 
  48. details on generating from/sender. (Section 3.2.6) 
  49.  
  50. Eliminate "denied"? "denied" is a way to say "you shouldn't have sent 
  51. me this". This is useful, so we'll keep it. 
  52.  
  53. 4) Discussion about mailing list support and list recipients (3.2.7). There 
  54. is a requirement by some U.S. government agencies to get a list of all 
  55. recipients of a message -- is this a good mechanism? Don't try to solve 
  56. this now. Is this mechanism proper for this draft? Defer for further 
  57. study? Yes, this is a rat hole. 
  58.  
  59.  
  60. 2. Work left for the I-D
  61. ------------------------
  62. Jim Galvin (?) will produce more text for the security section Keith 
  63. Moore will work on the Mailing list section and either approve the 
  64. current text or provide better wording. All new text and additional 
  65. comments have to be sent to the mailing list by July 15th.
  66. Roger Fajman will update the I-D by end of July. 
  67.  
  68.  
  69. 3. Usage of RECEIPT work for EDI
  70. --------------------------------
  71. It has been discussed how the prposed receipts can be used by the 
  72. EDIINT working group. Their requirements are signed receipts. It has 
  73. been accepted to extend the I-D if needed by EDIINT. (Later discussions 
  74. after the meeting showed, that they will most probably define a new 
  75. notification type signed-receipt and therefore will use the NOTARY 
  76. framework but be independent of NOTARY.)
  77.  
  78.  
  79. 4. Other extensions
  80. -------------------
  81. Perhaps we should add parameters to disposition-notification? 
  82. Concensus that we need parameters. One header or two headers? A sub-
  83. group will make a solid proposal by July 15th. Ned Freed will work on 
  84. it.
  85.  
  86.  
  87. 5. Other work related to RECEIPT
  88. --------------------------------
  89. Vacation- / Change of address - notifications 
  90.  
  91. The group decided, that these are not receipts. A data format might be 
  92. needed to support automated handling. The tasks are not close enough 
  93. to the current charter of the working group to justify inclusion. If 
  94. someone wants it bad enough, he can come up with a proposal and 
  95. publish it as an I-D and get a working group started on it.
  96.