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

[carl@xxxxxxxxx (Carl Hage)]

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