From owner-ietf-ediint@mail.imc.org Sun Mar 2 01:28:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25685 for ; Sun, 2 Mar 2003 01:28:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h226DLB06029 for ietf-ediint-bks; Sat, 1 Mar 2003 22:13:21 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h226DFY06020 for ; Sat, 1 Mar 2003 22:13:15 -0800 (PST) Received: from VALUED7B9600FA (pcp049386pcs.trnrsv01.nj.comcast.net [68.46.12.182]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan 7 2003)) with SMTP id <0HB3004YNYM0WF@mtaout04.icomcast.net> for ietf-ediint@imc.org; Sun, 02 Mar 2003 01:13:14 -0500 (EST) Date: Sun, 02 Mar 2003 01:13:02 -0500 From: Dave Killough Subject: Response when no MDN has been requested To: ietf-ediint@imc.org Message-id: <007301c2e082$c80c1300$6301a8c0@VALUED7B9600FA> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_soyQjDPRMeqksGu6UdnpSA)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_soyQjDPRMeqksGu6UdnpSA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT When there is no disposition-notification-to header in the client request, I am not returning an MDN. What should I return instead? There's one web server I'm testing that will generate an HTTP error if I don't provide some content-type. RFC 2298 was meant for email and does not discuss HTTP. Will I be ok with the following? : ########################################################################## # The posting client has not requested an MDN. None will be sent. # # EDIINT-AS2 DRAFT 1-2003 7.6 excerpt: # The HTTP server-side application may respond with an unsolicited # multipart/report as a message body that the HTTP client might not have # solicited, but this may be discarded by the client. Applications should # avoid emitting unsolicited receipt replies because bandwidth or # processing limitations might have led administrators to suspend asking # for acknowledgements. # print "content-type: text/plain\n"; print "connection: close\n"; print "\nposted without MDN request (disposition-notification-to)"; Thanks, Dave --Boundary_(ID_soyQjDPRMeqksGu6UdnpSA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
When there is no disposition-notification-to header in the client request, I am not returning an MDN. 
 
What should I return instead?  There's one web server I'm testing that will generate an HTTP error if I don't provide some content-type.  
 
RFC 2298 was meant for email and does not discuss HTTP.
 
Will I be ok with the following?   : 
   
    ##########################################################################
    # The posting client has not requested an MDN.  None will be sent.
    #
    # EDIINT-AS2 DRAFT 1-2003 7.6 excerpt:
    # The HTTP server-side application may respond with an unsolicited
    # multipart/report as a message body that the HTTP client might not have
    # solicited, but this may be discarded by the client. Applications should
    # avoid emitting unsolicited receipt replies because bandwidth or
    # processing limitations might have led administrators to suspend asking
    # for acknowledgements.
    #
    print "content-type: text/plain\n";
    print "connection: close\n";
    print "\nposted without MDN request (disposition-notification-to)";
 
Thanks,
Dave
--Boundary_(ID_soyQjDPRMeqksGu6UdnpSA)-- From owner-ietf-ediint@mail.imc.org Mon Mar 3 23:09:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23118 for ; Mon, 3 Mar 2003 23:09:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h243uV500779 for ietf-ediint-bks; Mon, 3 Mar 2003 19:56:31 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h243uTX00774 for ; Mon, 3 Mar 2003 19:56:29 -0800 (PST) Received: from VALUED7B9600FA (pcp049386pcs.trnrsv01.nj.comcast.net [68.46.12.182]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <0HB7009ZNHM394@mtaout02.icomcast.net> for ietf-ediint@imc.org; Mon, 03 Mar 2003 22:56:28 -0500 (EST) Date: Mon, 03 Mar 2003 22:56:26 -0500 From: Dave Killough Subject: AS2 draft 12 To: ietf-ediint@imc.org Message-id: <000501c2e202$07867720$6301a8c0@VALUED7B9600FA> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I think "5.2.3 Lengthy message bodies" got cut out of the draft. 5.2.2 Epilogue must be empty In [3] section 3.7.2, it is explicitly noted that multiparts must have null epilogues. ????????????????? In [4], sections 5.4.1, options for large file processing are discussed for SMTP transport. For HTTP, large files should be handled correctly by the TCP layer. However, [3] sections 3.5 and 3.6 discuss some options for compressing or chunking entities to be transferred. [3] section 8.1.2.2 discusses a pipelining option that is useful for segmenting large amounts of data. From owner-ietf-ediint@mail.imc.org Wed Mar 5 10:04:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02883 for ; Wed, 5 Mar 2003 10:04:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25Emld23708 for ietf-ediint-bks; Wed, 5 Mar 2003 06:48:47 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Emf323701 for ; Wed, 5 Mar 2003 06:48:41 -0800 (PST) Received: from VALUED7B9600FA (pcp049386pcs.trnrsv01.nj.comcast.net [68.46.12.182]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <0HBA005IN6GZYZ@mtaout04.icomcast.net> for ietf-ediint@imc.org; Wed, 05 Mar 2003 09:48:37 -0500 (EST) Date: Wed, 05 Mar 2003 09:48:32 -0500 From: Dave Killough Subject: AS#2 Example Software To: ietf-ediint@imc.org Message-id: <003001c2e326$4b265160$6301a8c0@VALUED7B9600FA> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_Z4uXk3m0v67J26u23cF9Qw)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-ietf-ediint@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_Z4uXk3m0v67J26u23cF9Qw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Working software that is available to this group would help clarify and fine-tune the draft. Unless anyone has this to share, I am willing to develop the software. The feaure set would include: - AS2 transfer of files over the Internet (sender directory to receiver directory) - Portability between Unix, Linux, and Windows - A user interface for configuration and operation, and monitoring - Documentation - Message and MDN tracking - Certificate management - A test run to demonstrate compliancy with the standard - Ability to use Apache or IIS for HTTP services I would start with the AS2 S/MIME variant, then PGP. Optional features would not be a priority. AS1 would come last if at all. The immediate goal is to have baseline compliancy with AS2. Based on the value this software would probably have to the Internet community as a whole, it would be also made available for free under some kind of open source license. This should accelerate adoption of the standard. It is cost-prohibitive for me to participate in interoperability testing with commercial vendors. Perhaps there are members who own licensed AS2 products that can help with these kinds of tests. Thanks, Dave Killough Programmer Williamstown, NJ USA killougd1@comcast.net --Boundary_(ID_Z4uXk3m0v67J26u23cF9Qw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Working software that is available to this group would help clarify and fine-tune the draft.  Unless anyone has this to share, I am willing to develop the software. 
 
The feaure set would include:
- AS2 transfer of files over the Internet (sender directory to receiver directory)
- Portability between Unix, Linux, and Windows
- A user interface for configuration and operation, and monitoring
- Documentation
- Message and MDN tracking
- Certificate management
- A test run to demonstrate compliancy with the standard
- Ability to use Apache or IIS for HTTP services
 
I would start with the AS2 S/MIME variant, then PGP. Optional features would not be a priority.  AS1 would come last if at all.  The immediate goal is to have baseline compliancy with AS2.
 
Based on the value this software would probably have to the Internet community as a whole, it would be also made available for free under some kind of open source license.  This should accelerate adoption of the standard. 
 
It is cost-prohibitive for me to participate in interoperability testing with commercial vendors.  Perhaps there are members who own licensed AS2 products that can help with these kinds of tests. 
 
Thanks,
Dave Killough
Programmer
Williamstown, NJ
USA
 
 
 
 
 
 
--Boundary_(ID_Z4uXk3m0v67J26u23cF9Qw)--