headers
E. Peter McKinney, CA | 5 Mar 1996 04:51

Re: ** Statement Summary #7 - Final

Rik,

You said that you did not see what my editorial comment meant, so I have
re-arranged the paragraphs for you to be more clear.

Cheers

Peter

>----Non Message Security Section----
>
>15REQUIREMENT : Delivery notification.
>17 ISSUE : Currently, you can get from a VAN separate sets of messages
>denoting message delivery, in advance of a 997. Given that ISPs do not have
>the management software to provide similar support, it might be advisable
>for IETF-EDI to be aware of and perhaps integrate the notification work now
>going on Title : An Extensible Message Format for Delivery Status
>Notifications Author(s) : K. Moore, G. Vaudreuil  Filename :
>draft-ietf-notary-mime-delivery-07.txt  Pages : 35  Date : 09/21/1995
>
>
>16 REQUIREMENT : WWW - HTML Integration with EDI
>19  ISSUE : As electronic commerce expands across the Internet, there could
>be ways to ease that expansion through support of smoother integration
>paths between the WWW's HTML pages and EDI messages. This has been bounced
>around in the EDI-L list and could assist the fulfillment process that
>site's need to execute.
>
>
>18 REQUIREMENT : EDI via secure FTP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl Hage | 5 Mar 1996 18:43

Re: ** Statement Summary #7 - Final

epmck <at> ns.RezoNet.NET ("E. Peter McKinney, CA") writes:
: >
: >18 REQUIREMENT : EDI via secure FTP
: >
: >20 ISSUE : As Wal-Mart does in the direct dial world, there will be
: >companies who wish to have their trading partners access a server for
: >requesting EDI messages or sending EDI messages. Are there issues IETF-EDI
: >needs to address in this area ?

What do you mean by this? What kind of messages are exchanged this way?
What is meant by "access a server"?

If the purpose is to bypass a VAN/ISP with direct dial or telnet access,
then SMTP/POP3 protocols can be used to retrieve and post messages
(with PPP for direct dial). However, I really don't see a reason to
do this. It seems better to use a standard mailer interface for
messaging (either direct or forwarded) rather than having multiple
protocols which are used for one TP-TP message transfer.

Perhaps Wal-Mart (or a VAN) keeps a log of messages in an FTP directory.
Then a standard format definition for these logs might be appropriate.

Perhaps a list of RFQs are placed in a file system directory. Then a
standard way of posting them would be useful.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<email:carl <at> chage.com> Voice/Fax: 1-408-244-8410       1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 5 Mar 1996 17:35

* Status or EDI over Internet WG - EDIINT

We  developed the list of EDI over Internet issues via brainstorming through late Feb. These issues are now
being edited and combined by two of the group's members: Mats Jansson and Chuck Shih.

As soon as they get done we will re-distribute the list, prioritize the list items as a group and then discuss
and resolve the higher priority items.  

Also we must put together an outline of the paper. It is due by the end of March, 1996.

My first thoughts on the paper outline are:

1 Background of EDI over Internet
        - Why 
        - Who is involved
        - CommerceNet involvement
        - Other
2 Identified issues (prioritized)
        - Issue 1
        - Issue 2
        - Issue 3
        - etc.
3 Issues solved with existing standards -- recommend standard and process
        - Issue 7
        - Recommendation
        - Issue 12
        - Recommendation
        - etc.
4 Issues which need something new or are not being address elsewhere
        - Issue 1
        - Recommendation
        - Issue 2
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 9 Mar 1996 07:15

** ACTION Statement Edits #1-14

This is the first section of the issues for EDI over Internet. If we did not get you comments in the first
round, please forgive us. Submit them in this round. 

I would like thank our editors Chuck Shih and Mats Jansson for their effort on  organized the responses. 

ACTION: 

Let us spend until next Friday (six days) doing two things:

1)  adding additional comments or solution recommendations to these in the same form as below

The form of response should look like 

                        "23 Comments: From Sally  Jones
                                  blaw, blaw......."

2) vote on which items to address first. We have so many issues identified that we will have to attack them in
some order.

The voting response should be as the example below shows:

                Priority 1: xx issue 

                Which means the most important statement is "xx Issue".

Let vote for the top ten in this round.  Your response should look like:

                To: ietf-ediint <at> imc.org
                From: Sally Jones
                Subject: ** EDIINT Vote
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rik Drummond | 9 Mar 1996 07:15

** ACTION Statement Edits #15-28


****************************************************************************
15 REQUIREMENT: ACKNOWLEDGMENTS/DELIVERY NOTIFICATION (Original #15 and #17)
The specification must describe what type of notifications and
acknowledgments a sender should receive, taking into consideration Non-
repudiation of receipt, 997's, 993's, AUTACK's, and existing pre-997 VAN-
provided delivery status.

15 COMMENT: From Unknown
Currently, you can get from a VAN separate sets of messages
denoting message delivery, in advance of a 997. Given that ISPs do not have
the management software to provide similar support, it might be advisable
for IETF-EDI to be aware of and perhaps integrate the notification work now
going on Title : An Extensible Message Format for Delivery Status
Notifications Author(s) : K. Moore, G. Vaudreuil  Filename :
draft-ietf-notary-mime-delivery-07.txt  Pages : 35  Date : 09/21/1995

15 COMMENT: From Carl Hage
This is now <ftp://ds.internic.net/rfc/rfc1894.txt>. 
There are also some related RFCs:
    -The Multipart/Report Content Type for the Reporting of Mail System
    Administrative Messages <ftp://ds.internic.net/rfc/rfc1892.txt>
    -Enhanced Mail System Status Codes <ftp://ds.internic.net/rfc/rfc1893.txt>
    -An Extensible Message Format for Message Disposition Notifications
    <ftp://ds.internic.net/internet-drafts/draft-ietf-receipt-mdn-00.txt>

15 COMMENT: From Harald Alvestrand
This is now an RFC (one of a set of four). RFC 1891-1894.

15 COMMENT: From Mats Jansson
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 10 Mar 1996 12:05

GEIS

Since it is important that we know what the EDI VAN guys are doing with the
Internet, I snipped the following off of GEIS' Web pages.

Does anybody have more info on the operational spec of their "mutual
authentication model", e.g. are they using DES encryption? Kerberos
authentication? etc.

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

This is from:   http://www.geis.com/geis/press/pr020696.html

Contact: GE Information Services John Berry (301) 340-4244 

NEW GENERATION OF SECURE INTERNET COMMERCE
UNVEILED BY GE INFORMATION SERVICES 

"GE InterBusinessSM" Allows Internet Access to Business-to-Business
Electronic Commerce Solutions 

Rockville, MD, February 6, 1996 -- GE Information Services today announced
the launch of "GE InterBusinessSM," a new
electronic commerce offering that provides powerful security protection of
business transactions over the Internet. GE
InterBusinessSM combines encrypted dynamic session key, mutual
authentication, and advanced firewall technology. It is
based on standard Internet protocols and establishes a highly secure
"pipeline" through which a user can conduct electronic
data interchange, electronic messaging, and electronic file transfers, the
three key elements of electronic commerce and GE
Information Services.
(Continue reading)

Permalink | Reply | 0 comments |
headers
jenkins | 10 Mar 1996 12:40
Picon

EDINT VOTE

cc : drummond <at> onramp.net

Subject: EDINT Vote

>From Gordon Jenkins

priority 1   2 issue

priority 2   16 issue

priority 3   18 issue

priority 4   7 issue

priority 5   4 issue
--------------------------------------------------------------------------
 JENKINS  <at>  ASSOCIATES INC                jenkins <at> fox.nstn.ca          
--------------------------------------------------------------------------
GORDON JENKINS                                                                                                                     x

         CONSULTING IN ELECTRONIC COMMERCE AND INTERNET 

" helping you move from paper to electronic to compete" 

 http://infop.com/karoma:  Electronic Commerce Answer Page
 http://ARRAYdev.com:  Journal of Internet Banking and Commerce: Editor
 fax 613 723 8938           tel 613 723 1581         cel 613 794 6735                                                                                                                                                                              
-----------------------  OTTAWA ON CANADA -----------------------------                        

--VAA16267.826421336/Fox.nstn.ca--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Darnell | 10 Mar 1996 14:13

EDIINT VOTE

FROM DAVE DARNELL:

priority 1   2 issue
priority 2   12 issue
priority 3   15 issue
priority 4   18 issue
priority 5   4 issue
priority 6   9 issue
priority 7   17 issue
priority 8   20 issue
priority 9   22 issue
priority 10   19 issue

Regards,
Dave
======================================
|   David Darnell              
|   SysTrends, Inc.             
|   Arizona EC/EDI Roundtable   
|   1850 East Carver Road       
|   Tempe, AZ 85284             
|   Tel (602)838-5316           
|   Fax (602)897-8032           
|   mailto://dave_d <at> systrends.com        
======================================
Permalink | Reply | 0 comments |
headers
Mark Thompson, EDI, REO2 F/D-2, dtn: 830-6363 11-Mar-1996 1757 | 11 Mar 1996 19:56
Picon

Re: Message Sequence Integrity

Hi,

Re:

>At 7:06 AM 2/16/96, Trevor Richards wrote:
>>Incidentally, X.25 and interconnected VANs can lead to interchange N+1
>>arriving before interchange N in todays' communications infrastructure.
>
>        Interesting.
>
>        X.25 is a connection protocol that is defined to deliver packets in
>order, over the same path (unlike IP.)
<

I would doubt, very much, that this is due to X.25 per se, rather
that it is an artifact of the store-and-forward system used by the VAN and
its retry algorithm.

Mark
Permalink | Reply | 0 comments |
headers
Carl Hage | 11 Mar 1996 20:48

Re: "transport" services for reliability and security

dcrocker <at> brandenburg.com (Dave Crocker) writes:
: =46olks,

[Those #$ <at> ! MIME mailreaders are out of control, corrupting messages that
don't need to be corrupted with automatic quoted printable. Can you
turn that darn thing off?]

: ... I've started
: proposing that we enhance the Internet Mail architecture to include a layer
: for [security and reliability]... Hence, email becomes:
: 
: 		UA-UTA-MTA-MTA-UTA-UA.
: 
: The purpose of the UTA architectural model is to perform reliability (and
: sequencing) functions usually attributed to transport-like services, as
: well as apply any security services that are required.

The RFCs related to email and EDI could support separate UA-UTA or
integrated approach, provided the wrapping of services are layered
appropriately. One could imagine a generic UTA that could deliver
decrypted/authenticated "Content-Type: message" to a plain mailreader, or
deliver selected MIME types (EDI or other) to a processing application.
Most all the functions of Internet EDI messaging could be handled by a
generic UTA. Corporate email gateways could perform the UTA function
for delivery to individual PCs within a corporate LAN.

There are a few tricky points, however. These aren't really addressed
by the current RFC1894, or draft-ietf-receipt-mdn-00.txt. One issue
is that it may be desirable to reduce the number of messages that need
to be processed, decoded, authenticated, etc., by combining a MDN
(Continue reading)

Permalink | Reply | 0 comments |

Gmane