[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AS#2 - Internet Draft P
- To: Carl Hage <carl@xxxxxxxxx>, ietf-ediint@xxxxxxx, Rik Drummond <drummond@xxxxxxxxxx>
- Subject: Re: AS#2 - Internet Draft P
- From: Wayne Seifried <Wayne.Seifried.0139577@xxxxxx>
- Date: Mon, 9 Dec 1996 14:41:26 +0000
- Sender: owner-ietf-ediint@xxxxxxx
- X400-content-type: P2-1984 (2)
- X400-mts-identifier: [/PRMD=NT/ADMD=MCI/C=US/;<n1361997515.59584@nmisq2.miss.n]
- X400-originator: Wayne.Seifried.0139577@nt.com
- X400-received: by mta NT.COM in /PRMD=NT/ADMD=MCI/C=US/; Relayed; Mon, 9 Dec 1996 15:09:56 +0000
- X400-received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed; Mon, 9 Dec 1996 14:48:43 +0000
- X400-received: by /PRMD=NT/ADMD=MCI/C=US/; Relayed; Mon, 9 Dec 1996 14:41:26 +0000
- X400-recipients: non-disclosure:;
Reply to: RE>>AS#2 - Internet Draft Proposal - 0/3
Carl Hage wrote...
- Private ID's are a potential problem. The internal ID's should
> be maintained _within_ an organization, and ID's based on
> InterNIC registered domain names should be used instead,
> e.g. edi@edi.xyzcorp.com, http://edi.xyzcorp.com, edi://edi.xyzcorp.com
>Re: use of internic names...this would severly limit the protocol to business to business commerce applications. I don't think we want to do that at this point. The protocol could support consumer based commerce as well ....and with an ISP environment where even IP addresses are dynamically assigned, limiting the address would seem to cause a problem.
wayne.seifried@nt.com
Internet Commerce
Nortel Enterprise Networks
--------------------------------------
Date: 12/8/96 7:57 PM
To: Wayne Seifried
From: Rik Drummond
----- E X T E R N A L L Y O R I G I N A T E D M E S S A G E -----
Thanks Carl...I am sure the author will respond to your comments...later..rik
At 4:02 PM 12/7/96, Carl Hage wrote:
>General Comment: This is a new protocol which duplicates the
> existing functionality already provided by AS#1,
> e.g. using SMTP/POP3, which is the ususal protocol
> for dialup Internet access.
>
>Issues:
>
> - POP3, which is widely supported both by ISPs with server software
> as well as in email clients, performs the functions not performed
> by SMTP. POP3 and IMAP are already covered by AS#1. In fact, I object
> to the use of the term "SMTP" with AS#1, since this is an RFC822
> email messaging protocol, which includes POP, IMAP, UUCP, and other
> message transfer protocols.
>
> The features in AS#2 draft that are not in SMTP, LIST, GETDOCS,
> are covered by POP3.
>
> IMAP, not widely supported like POP, extends the concepts in POP
> to permit management of remote mailboxes, and this isn't really
> needed for EDI messaging.
>
> - Private ID's are a potential problem. The internal ID's should
> be maintained _within_ an organization, and ID's based on
> InterNIC registered domain names should be used instead,
> e.g. edi@edi.xyzcorp.com, http://edi.xyzcorp.com, edi://edi.xyzcorp.com
>
> - Message ordering in internet EDI could be best addressed by
> either using an extended message header, or adopt an agreed upon
> "Subject:" and or "Message-ID:" header, e.g.
> Subject: X12 Interchange 000000123
> where 000000123 is the interchange control number.
> Likewise, the "From:" header could include the TP id, e.g.
> From: edi@edi.xyzcorp.com (Xenophobic Yak Zoos EDI, DUNS=123434)
>
> - AS#1 also supports broadcasting of RFQ's, etc. over email lists and
> NNTP. However, there are no header formatting standards that would
> allow filtering and selection based on SIC code, etc. (This isn't
> covered by the AS#2 draft either.)
>
> - AS#2 does not provide non-repudiation, whereas AS#1 does.
>
> - Not really discussed before are features that facilitate auditing
> and non-repudiation. For example, consider a MIME type which is
> a request for a receipt of a message summary, e.g. messages sent
> or received, returned as a MIME type. The message summary would
> contain a list of messages, e.g. with date/time, message-ID,
> interchange#, md5 of the contents or interchange, etc. Such a
> message might be sent by an auditor of one TP to obtain a list
> and match md5 MACs against a log of transactions. An interesting
> feature in a message summary request might be third party
> authorization, e.g. xyzcorp.com authorized audits.com to make such
> a request. (Actually only the MD5s are really needed by an auditor,
> which doesn't reveal anything other than number of transactions,
> unless one has the log.)
>--------------------------------------------------------------------------
>Carl Hage C. Hage Associates
><email:carl@chage.com> Voice/Fax: 1-408-244-8410 1180 Reed Ave #51
><http://www.chage.com/chage/> Sunnyvale, CA 94086
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Brentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------
------------------ RFC822 Header Follows ------------------
Received: by nmisq2.miss.nt.com with SMTP;8 Dec 1996 19:55:57 -0500
Received: from mail.proper.com by ntigate.rich.nt.com with SMTP (PP);
Mon, 9 Dec 1996 00:43:58 +0000
Received: (from majordomo@localhost) by mail.proper.com (8.8.3/8.7.3)
id PAA00290 for ietf-ediint-bks; Sun, 8 Dec 1996 15:53:06 -0800 (PST)
X-Authentication-Warning: mail.proper.com: majordomo set sender to
owner-ietf-ediint using -f
Received: from mailhost.onramp.net (mailhost.onramp.net [199.1.11.3])
by mail.proper.com (8.8.3/8.7.3) with ESMTP id PAA00285
for <ietf-ediint@imc.org>; Sun, 8 Dec 1996 15:53:03 -0800 (PST)
Received: from [199.184.212.210] (stockyard47.onramp.net [199.184.212.210])
by mailhost.onramp.net (8.7.3/8.6.5) with SMTP id RAA15565;
Sun, 8 Dec 1996 17:23:26 -0600 (CST)
Message-Id: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 8 Dec 1996 17:25:35 -0600
To: carl@chage.com (Carl Hage), ietf-ediint@imc.org
From: drummond@onramp.net (Rik Drummond)
Subject: Re: AS#2 - Internet Draft Proposal - 0/3
Sender: owner-ietf-ediint@imc.org
Precedence: bulk