[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AS#2 - Internet Draft Proposal - 1/3
PRPOSAL / PROPOSAL / PROPOSAL / PROPOSAL / PROPOSAL / PROPOSAL
INTERNET DRAFT Kent Schwab, Actra
05 December, 1996
Electronic Commerce Transfer Protocol (ECTP)
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet Drafts
as reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
This document defines an application-layer protocol for conducting
electronic commerce over a connection-oriented transport (such as SSL).
It derives from SMTP (RFC821/822) and NNTP(RFC977), and relies on MIME
encapsulation. It is a conversational-model protocol, which assumes a
persistent connection, targeted at moving and administering electronic
commerce documents.
Feedback Instructions:
If you want to provide feedback on this draft, follow these guidelines:
-Send feedback via email to kents@actracorp.com, chucks@actracorp.com,
and lincoln@actracorp.com with "ECTP" in the Subject field.
-Be specific as to what section you are referring to, preferably
quoting the portion that needs modification, after which you state
your comments.
-If you are recommending some text to be replaced with your suggested
text, again, quote the section to be replaced, and be clear on the
section in question.
-If you are questioning fundamental methods, make it clear to us and
we will bring the issue to the ediint list for discussion. To follow
the discussion, you need to subscribe at ietf-ediint@imc.org.
Table of Contents
I. INTRODUCTION
1.1. Purpose of this document
1.2. Intended Audience
1.3. Relationship to NNTP - RFC977, SMTP - RFC821 and 822, and MIME -
RFC1521
II. THE ECTP MODEL
2.1. Goals of ECTP
2.2. Base Protocols
2.3. Model of Operation
III. THE ECTP PROCEDURES
3.1. OPEN and CLOSE
3.2. SEND
3.3. Query and Enumeration
3.4. Document Retrieval
IV. THE ECTP SPECIFICATION
4.1. Overview
4.2. Character Set
4.3. Commands
4.4. Responses
4.4.1. Data Responses
4.4.2. Status Responses
4.4.3 General Responses
V. COMMAND AND RESPONSE DETAILS
5.1. The DATA Command
5.1.1. DATA
5.1.2 Response to DATA
5.2. The GETDOCS Command
5.2.1. GETDOCS
5.2.2. Responses to GETDOCS
5.3. The HELO command
5.3.1. HELO
5.3.2. Responses to HELO
5.4. The HELP Command
5.4.1. HELP
5.4.2. Responses to HELP
5.5. The LIST command
5.5.1. LIST
5.5.2. Responses to LIST
5.6. The NEXT Command
5.6.1. NEXT
5.6.2. Responses to NEXT
5.7. The QUIT command
5.7.1. QUIT
5.7.2. Responses
5.8. The RCPT Command
5.8.1. RCPT
5.8.2. Responses to RCPT
5.9. The SEND command
5.9.1. SEND
5.9.2. Responses to SEND
5.10. Command Summary
5.11. Minimal Command Implementation
5.12. Summary of Responses
VI. REFERENCES
APPENDIX A - ALTERNATIVE PROTOCOL / EC FUNCTION COMPARISON
I. Introduction
For years, Electronic Commerce was defined as the transfer of documents
or messages between companies using, primarily, the services of a Value
Added Network (VAN). Companies trading EDI documents had a mechanism for
'normalizing' the documents, according to the ANSI and EDIFACT document
standards, but had no common means of transferring the documents between
trading partners. Many VANs provided:
- mailboxing services
- common connectivity clearinghouses (trading partners did not have to
share the same connection mechanism with the VAN)
- store and retrieve of EDI documents and messages - a user pull model.
- enforced trading partner restrictions
- document or message status reporting
The VANs have done an excellent job of providing such services,
supporting an essentially batch model of transfer. In most cases, the
volume of documents exchanged dictates the cost of the VAN service.
The advent of the Internet has opened many alternatives to the batch VAN
model. The CommerceNet EDI interoperability test, which began in
October, 1996, with an open standard based on SMTP and S/MIME, paves the
way for securely sending Electronic Commerce ("EC") documents and
messages via the Internet.
But this first use of the Internet for EC is a datagram, or postoffice,
model. Such a model, which can not guarantee document delivery, nor
dictate order of delivery, makes the VAN model viable, with the VAN's
ability to track document status. The content of the message or document
in the SMTP/SMIME model can be assured (it has not been altered along
the way), but the delivery cannot.
What is required is a secure socket connection on which to base an
application-level protocol like SMTP. It is the author's belief,
however, that while SMTP's SEND mechanism is an excellent model for the
movement of the data, it lacks many of the other services supportive of
an EC community, the structure for many of which are supplied in the
NNTP protocol.
SMTP's SEND provides the core of the 'push' model for data movement in
the Internet environment; NNTP's enumeration and retrieval commands
provide more robust surrounds.
Therefore, the next step is a connection-oriented model, which can
guarantee secure delivery immediately, with guaranteed non-repudiation,
capable of carrying hashed or signed documents or parts, with immediate
or interactive capabilities. This document proposes an application-layer
protocol, based on NNTP and SMTP, for use over a secure connection such
as SSL. Further, to optionally carry hash or document signatures, the
data content carried by the protocol is proposed to be minimally MIME,
and potentially S/MIME, depending on the specific business need.
1.1. Purpose of this document
The purpose of this document is to define the application-layer
protocol, termed Electronic Commerce Transfer Protocol ("ECTP"), to ride
on top of a secure socket connection (such as SSL), and which is capable
of encapsulating application-specific body parts, according to the MIME
specification [1]. The protocol must be capable of utilizing S/MIME[2]
for document content requiring electronic signature and encryption. The
intent is to address the needs of the Electronic Commerce community, in
securely conducting EC-business over the Internet. Documents can be
considered traditional EDI messages, private data formats, or even
transactions of an application-to-application nature; the concept of a
Content-Type header in integral to the protocol specified here[3].
This protocol specification, based on RFC977 for NNTP[4], RFC 821 for
SMTP[5], RFC 822[6], RFC 1521 for MIME and Mail encoding, and RFC 1767
for MIME Encapsulation of EDI Objects[7], refines the syntax and
semantics for the EC community to provide both interactive/connection-
oriented services in balance to less-robust datagram services for
Electronic Commerce. It is intended that voluntary interoperability
testing of this protocol would be a follow on to the SMTP/MIME testing.
1.2. Intended Audience
The audience for this document is both the interested party in
understanding the level of EC services proposed by ECTP, and the
implementers who must use the protocol to conduct Internet-based, point-
to-point Electronic Commerce. It is assumed that the reader intending to
implement the protocol has read and understood the requirements for
establishing a secure socket connection (e.g. SSL), and has, if
required, understood the MIME/SMIME techniques required to encapsulate
the data. This document concentrates exclusively on the application-
layer protocol for the client-server, request-response model of ECTP.
1.3. Relationship to NNTP - RFC977, SMTP - RFC821 and 822, and MIME -
RFC1521
The NNTP specification is targeted to the Newsgroup user/developer. The
commands are syntactically targeted to that domain, and the protocol
semantics are targeted as well to dealing with articles, groups of
articles, and the threading or connecting of articles; further
extensions to NNTP have dealt with the searching of data within
articles.
ECTP shares the NNTP protocol's ability to enumerate and inquire on
server-based documents (articles in its case) - the LIST, GROUP, and
DOCUMENT request commands.
SMTP concentrates on mail addressing, routing and delivery. The target
of MIME encapsulation has been document delivery, and it is that part of
the SMTP protocol that is incorporated into ECTP. From SMTP, ECTP
inherits all of the document encapsulation and movement services (e.g.
SEND).
In those cases where NNTP commands have been adopted, the structure of
NNTP and the general model of its operation have been retained to
leverage existing NNTP implementations and expertise. Likewise, where
commands have been inherited from SMTP, that syntax and semantics have
been unchanged to the greatest extent possible. MIME support has been
directly inherited, along with support for RFC 1767, EDI MIME-types[7].
Fortunately, both NNTP and SMTP share a similar command/response model,
and it is hoped that the implementers of the protocol will be able to
share code from these installed systems.
II. The ECTP Model
2.1. Goals of ECTP
As previously noted, a document from ECTP's perspective is defined as a
unit of transmission or enumeration. It may be a file containing
multiple traditional EDI interchanges, a single EDI interchange or
document/message, a 'blob' of private data, or a transaction used to
support interactive operations. The ECTP protocol is more than a method
for delivering such data objects from one location to another over the
Internet. The protocol must support the full range of operations needed
by two electronic trading partners or applications. It must, most
certainly, be capable of moving documents or data objects securely from
one point to another. But it must also support query and enumeration
capabilities on documents, and demand the transfer of selected data
objects.
The design and operation of the ECTP protocol must meet the following
goals:
- Be based, to the greatest extent possible, on known protocol models
used on the Internet in order to capitalize on existing code and
knowledge.
- Support the full range of operations needed to support Electronic
Commerce between business entities.
- Support ordered deliver of documents; that is, it must be possible to
guarantee that the order that one partner sends data objects is the
order in which the other partner receives them.
- Be capable of sending and receiving any type or types of content
information including, but not limited to, wide character streams, EDI
data encapsulated in MIME, and private data formats.
- Be capable of supporting batch as well as real-time, 'conversational'
interaction between processes across locations. This includes receipt of
acknowledgments during the same connection as document submission for
traditional EDI messages, and the support for transaction processing
between client and server applications.
- Rely on the underlying transport protocol to provide secure transfer,
and to authenticate users at both ends of the circuit.
2.2. Base Protocols
ECTP derives from SMTP for document movement. Since later derivations of
SMTP know how to move MIME-encapsulated body parts, ECTP capitalizes on
that protocol to move any type of content.
The GROUP concepts of NNTP are the base from which ECTP derives it query
capabilities.
The positive news is that both of these base protocols share the same
simple, syntactic view of the world: they are request-response models
which use simple command streams to invoke a service, and they share the
same encoding concepts.
Merging the capabilities of the two, changing some of the names of the
commands to match the domain, causes no conflicts in model of operation.
Derived from open standards, the intent of ECTP is also to be open.
It is assumed that the transport mechanism, such as SSL, will provide
both a secure connection, and a mechanism for user authentication (such
as certificate exchange). It will not be considered part of the
application-layer protocol design, even though SSL seems to be the most
popular transport mechanism choice.
2.3. Model of Operation
The ECTP design is based on the following model of communication:
- Based on a user interface request, an application process, a
scheduled operation, or some other trigger, the client establishes a
two-way transmission channel to the server, using a secure transport
mechanism (such as SSL).
- Unlike SMTP, the server contacted must be the ultimate destination.
Certificates, or some other mechanism used by the transport mechanism,
are exchanged to guarantee authenticity and privilege.
- ECTP commands are generated by the client and sent to the server.
ECTP replies are sent from the server to the client in response to the
commands.
- Once the transmission channel is established, the client sends a
valid command (such as SEND) to the server, with all required parameters
according to the definition of the command.
- Once the channel is established, the client may initiate as many
commands as required before the channel is closed with the QUIT command.
- Commands may well be 'linked', in that the response from one command
is logically linked to the next command. In a classical SMTP scenario,
for example, a positive response by the server to a SEND command would
normally expect a RCPT command identifying a recipient.
- In ECTP there is no relaying and distribution concept; the request
for RCPT would be singular. All interactions are between client and
server.
- Data is exchanged as raw, MIME, or S/MIME encapsulated body part or
parts with the server. In the transaction processing, interactive model
of operation, the data object sent to the server may be a coded request
for service, with the response being the data corresponding to the
request.
- Enumeration functions, derived from NNTP, support data object inquiry
and retrieval from the server..
Note that, like SMTP and NNTP, the dialog of interaction between client
and server is purposely lock-step, one-at-a-time.
The implementation of the minimal subset of ECTP imposes a 'Push' model
for data movement, consistent with SMTP. That is, all data moves only
from the client to the server; there are no commands to retrieve data or
metadata from the server in the minimal subset. To move data in the
opposite direction, a separate connection is established, and the roles
of client and server are reversed. This minimal set is all that is
required to physically move data from client to server, and can support
both an interactive, conversational model of operation, as well a full
MIME-encapsulated, multipart file-oriented data transfer model. The
NNTP-based commands found in ECTP support movement of data from server
to client and supportive inquiry functions, all in a single session. It
is believed that the cost of establishing a secure connection has a
better payback when all required operations can be performed in a single
session. Since the server will not normally exercise a dial-up PPP or
SLIP connection, dial-up clients who wish to receive data from the
server must implement more than the minimal subset of ECTP.
The ECTP commands and replies have a rigid syntax. Replies conform to
the SMTP and NNTP syntax of containing a numeric code and person-
readable text. The complete list of commands and replies appear in
Section 4 on specifications.
Commands and replies are not case sensitive. That is, a command or
reply word may be upper case, lower case, or any mixture of upper and
lower case. Note that this is not true of user names. That is, it can
not be assumed that a trading partner identified by short name KENT on a
given server is the same as Kent or kent. ECTP implementations must
take care to preserve the case of user names as they appear in transfer,
enumeration, or setup arguments.
Like SMTP, commands and replies are composed of characters from the
ASCII character set. When the transport service provides an 8-bit byte
(octet) transmission channel, each 7-bit character is transmitted
right justified in an octet with the high order bit cleared to zero.
Note that ECTP incorporates all of the enhancements to SMTP to perform
encoding and transmission of all octet streams [8].
III. The ECTP Procedures
This section is intended to show the overall flow of information between
ECTP client and server. The purpose is to highlight the overall way in
which a conversation is established and destroyed, and to demonstrate
normal conversational flow to accomplish common operations.
3.1. OPEN and CLOSE
At the time the transmission channel is opened there is an exchange to
note start of communications. Since ECTP is based on a secure channel
connection, with exchange of certificates or some other such method to
authenticate the parties, the HELO is retained for SMTP compatibility.
The following two commands are used in transmission channel opening and
closing:
HELO <CRLF>
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Brentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------