[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: RFC 3335 on MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet
(BDear members of EDIINT,
(BCongratulations that EDIINT as1 becomes RFC.
(BIf anyone has some information about the followings, please let me know.
(BWhat company or industry has adopted EDIINT as1 or as2?
(BWhat company or industry is going to adopt EDIINT as1 or as2?
(BHow many companies or industries adopted or are going to adopt EDIINT as1 or
(BIf you have a bit of information about above, it is very valuable
(Binformation for us.
(BWe (ECOM in Japan) is studying B2B standards and implementations in the
(Bworld, and we will inform these information to industries and It vendors in
(BThanks in advance,
(BElectronic Commerce Promotion Council of Japan (ECOM)
(BTel: +81-3-3436-7542 Fax: +81-3-3436-7570
(B----- Original Message -----
(BCc: <rfc-editor@xxxxxxxxxxxxxx>; <ietf-ediint@xxxxxxx>
(BSent: Tuesday, September 17, 2002 8:52 AM
(BSubject: RFC 3335 on MIME-based Secure Peer-to-Peer Business Data
(BInterchange over the Internet
(BA new Request for Comments is now available in online RFC libraries.
(B RFC 3335
(B Title: MIME-based Secure Peer-to-Peer Business Data
(B Interchange over the Internet
(B Author(s): T. Harding, R. Drummond, C. Shih
(B Status: Standards Track
(BDate: September 2002
(B Mailbox: tharding@xxxxxxxxxxxxxxxxxxx,
(B chuck.shih@xxxxxxxxxxx, rik@xxxxxxxxxxxxxxxxx
(B Pages: 29
(B Characters: 59687
(B Updates/Obsoletes/SeeAlso: None
(B I-D Tag: draft-ietf-ediint-asl-17.txt
(B URL: ftp://ftp.rfc-editor.org/in-notes/rfc3335.txt
(BThis document describes how to exchange structured business data
(Bsecurely using SMTP transport for Electronic Data Interchange,
(B(EDI - either the American Standards Committee X12 or UN/EDIFACT,
(BElectronic Data Interchange for Administration, Commerce and
(BTransport), XML or other data used for business to business data
(Binterchange. The data is packaged using standard MIME content-types.
(BAuthentication and privacy are obtained by using Cryptographic Message
(BSyntax (S/MIME) or OpenPGP security body parts. Authenticated
(Backnowledgements make use of multipart/signed replies to the original
(BThis document is a product of the Electronic Data Interchange-Internet
(BIntegration Working Group of the IETF.
(BThis is now a Proposed Standard Protocol.
(BThis document specifies an Internet standards track protocol for the
(BInternet community, and requests discussion and suggestions for
(Bimprovements. Please refer to the current edition of the "Internet
(BOfficial Protocol Standards" (STD 1) for the standardization state and
(Bstatus of this protocol. Distribution of this memo is unlimited.
(BThis announcement is sent to the IETF list and the RFC-DIST list.
(BRequests to be added to or deleted from the IETF distribution list
(Bshould be sent to IETF-REQUEST@xxxxxxxxx Requests to be
(Badded to or deleted from the RFC-DIST distribution list should
(Bbe sent to RFC-DIST-REQUEST@xxxxxxxxxxxxxxx
(BDetails on obtaining RFCs via FTP or EMAIL may be obtained by sending
(Ban EMAIL message to rfc-info@xxxxxxxxxxxxxx with the message body
(Bhelp: ways_to_get_rfcs. For example:
(B To: rfc-info@xxxxxxxxxxxxxx
(B Subject: getting rfcs
(B help: ways_to_get_rfcs
(BRequests for special distribution should be addressed to either the
(Bauthor of the RFC in question, or to RFC-Manager@xxxxxxxxxxxxxxx Unless
(Bspecifically noted otherwise on the RFC itself, all RFCs are for
(BSubmissions for Requests for Comments should be sent to
(BRFC-EDITOR@xxxxxxxxxxxxxxx Please consult RFC 2223, Instructions to RFC
(BAuthors, for further information.
(BJoyce K. Reynolds and Sandy Ginoza
(BUSC/Information Sciences Institute
(BBelow is the data which will enable a MIME compliant Mail Reader
(Bimplementation to automatically retrieve the ASCII version
(Bof the RFCs.