Re: AS#2 - Internet Draft Proposal - 0/3

[drummond@xxxxxxxxxx (Rik Drummond)]

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      |
------------------------------------------------------