[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AS#2 - Internet Draft Proposal - 3/3
All text, if any, in the response which is not a parameter of the
response must follow and be separated from the last parameter by a
space. Also, note that the text following a response number may vary in
different implementations of the server. The 3-digit numeric code should
be used to determine what response was sent.
Response codes not specified in this standard may be used for any
installation-specific additional commands also not specified. These
should be chosen to fit the pattern of x8x specified above. (Note
that, like NNTP, debugging is provided for explicitly in the x9x
response codes.) The use of unspecified response codes for standard
commands is prohibited.
4.4.3. General Responses
The following is a list of general response codes that may be sent by
the ECTP server. These are not specific to any one command, but may be
returned as the result of a connection, a failure, or some unusual
condition.
In general, 1xx codes may be ignored or displayed as desired; code 200
or 201 is sent upon initial connection to the server depending upon
permission; code 400 will be sent when the server discontinues service
(by operator request, for example); and 5xx codes indicate that the
command could not be performed for some unusual reason.
100 help text
190 through 199 debug output
200 server ready - SEND allowed
201 server ready - no SEND allowed
215 OK - List Follows
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
V. Command and Response Details
5.1. The DATA Command
The DATA command is used to signal that data is about to be sent from
the client to the server, in a SEND scenario, or that the client is
prepared to receive data from the server on DOCUMENT retrieval.
In the SEND situation, the client can specify a control number to be
used in tracking the data; the server will associate that control number
with the data. In any case, on successful receipt of the data by the
server, it will generate a unique tracking number on the server to
associate with the data; the number specified by the client, if any, can
not be assured to be unique for a given server.
5.1.1. DATA
DATA [senders_control_number]<CRLF>
5.1.2. Response to DATA
There are no responses to the DATA command in DOCUMENT retrieval. This
is the 'signal' command to the server that the client is ready to
receive the data. The response from the server is the data itself. In a
SEND environment, the DATA command from the client signals that it is
ready to send the data to the server, and optionally assigns a client-
owned tracking number for the data. In this case, the server signals the
client, if all is well, with the
354 Ready to Receive
interim response. If the server encounters a problem, it may send:
400 service discontinued
503 program fault - command not performed
indicating that the send of data from the client should not proceed.
For a SEND operation, the successful receipt of data is marked by the
server sending a
251 control_number Received OK
specifying a unique, server-generated tracking number for the data just
received. Otherwise, the server can send one of the following to
indicate a problem in the receipt:
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.2. The GETDOCS Command
The GETDOCS command, used in conjunction with the NEXT command, is a
shorthand for unretrieved document retrieval. It permits the client to
qualify the criteria for document retrieval, and then to next through
the documents that meet the criteria; the client does not need to
maintain the document ids returned from a LIST command. With no options
specified, the GETDOCS defines the set of documents intended for the
current client, which have not yet been retrieved by the client.
5.2.1. GETDOCS
GETDOCS[<SP><Condition><Relationship><Value>][<Connector>
<Condition><Relationship><Value>]
. <CRLF>
Where...
Condition = "STATUS", "TRADINGPARTNER", "DATE","DOCID"
Relationship = "=", "!=", "<", ">", "<=", ">="
Value = <String>, <Number>,<Date>,<StatusValue>
StatusValue = "Retrieved","Unretrieved","Sent" //from client
perspective
Date = <YYYYMMDD>
Connector = "AND", "OR"
5.2.2. Responses to GETDOCS
If no errors were found in the syntax or permissions of the GETDOCS
command, the server will return
210 Document Set Prepared
as long as the document set contains one or more documents. If the
GETDOCS command is correct, but yields no documents that meet the
criteria, the server will return
431 Set Empty
Else, the GETDOCS command will return:
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.3. The HELO command
The HELO command is inherited from SMTP, where it serves the purpose of
[unsecurely] specifying the client's domain. In the secure transport
environment, where authentication is managed, the HELO only provides a
mechanism, by means of its response, for determining the server's
ability to support document receipt. Transport must percolate the domain
up to the application layer protocol.
5.3.1. HELO
HELO <CRLF>
5.3.2. Responses to HELO
If the server is able to establish connection (initialize its tables and
state for this session) and it is capable of receiving new documents
(SEND) from the client, then
200 server ready - SEND allowed
If connection is OK but the client is not permitted to SEND new
documents to the server, the response is
201 server ready - no SEND allowed
else, if the connection cannot be established, the response is
502 access restriction or permission denied
503 program fault - command not performed
5.4. The HELP Command
The HELP command is used to force the server to enumerate the list of
commands that it supports.
5.4.1. HELP
HELP <CRLF>
5.4.2. Responses to HELP
If no problem:
215 List Follows
HELO <CRLF>
HELP <CRLF>
and so on until
. <CRLF>
If problem:
500 command not recognized
503 program fault - command not performed
5.5. The LIST command
The LIST command is used to enumerate documents on the server available
to the client. The LIST command does not retrieve the document, but
merely enumerates the available documents that meet the selection
criteria, for the current client with his privileges.
5.5.1. LIST
LIST[<SP><DOCUMENTS>][<SP><Connector><Condition><Relationship>
<Value>] <CRLF>
Where...
Condition = "STATUS", "TRADINGPARTNER", "DATE","DOCID","MAXHITS"
Relationship = "=", "!=", "<", ">", "<=", ">="
Value = <String>, <Number>,<Date>,<StatusValue>
StatusValue = "Retrieved","Unretrieved","Sent" //from client
perspective
Date = <YYYYMMDD>
TPID = <String>, <Number> with imbedded punctuation
5.5.2. Responses to LIST
If no errors were found in the syntax or permissions of the LIST
command, the server will return either
215 OK - List Follows if the entire list fits within
MAXHITS, if specified;
else
216 OK - Partial List Follows if NEXT must be used to complete the
list, since number of returns
exceeds MAXHITS specified.
as long as the document set contains one or more documents.
The format of each response line is
DocumentKey <SP>From<SP>To<SP>Status<SP>LastDate<SP>TrackingLabel <CRLF>
Where...
DocumentKey is the reference for retrieval of the document from the
Server("DOCID")
>From is the Originator's identifier
To is the Recipient's identifier
Status is the delivery/retrieval status of the
document/message
LastDate is the date which applies to the Status in YYYYMMDD format
TrackingLabel is an optional key (hint) associated with the document
as specified by the originator of the document
All LIST Commands that may deliver multiple response lines use the
.<CRLF> to mark the end of the list of responses. All fields which
contain embedded spaces must be surrounded in double quotation marks,
since the <SP> is the field delimiter.
If the LIST command is correct, but yields no records that meet the
criteria, the server will return
431 Set Empty
Else, the LIST command will return:
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.6. The NEXT Command
The NEXT command is used to retrieve members of the set generated with
the GETDOCS or LIST commands. It has no meaning on its own, and will
generate an error if no GETDOCS or LIST command has been issued, or if
another command has been issued since the GETDOCS or LIST command.
5.6.1. NEXT
NEXT <CRLF> to retrieve next
document for
GETDOCS, or
NEXT [<MAXHITS = >number] <CRLF> to retrieve the next set of
responses for LIST
5.6.2. Responses to NEXT
If no error is detected (a GETDOCS, LIST or NEXT was the last command,
and GETDOCS or LIST generated a non-null set) then the server will
respond:
240 Ready to Transfer for NEXT following GETDOCS
The client must then send the DATA command to begin the transfer from
server to client.
If the NEXT is used in response to a partial set returned by LIST, then
the response, under no error conditions, will be either:
215 OK - List Follows if the entire list fits within
MAXHITS, if specified; else
216 OK - Partial List Follows if NEXT must be used to complete the
list
The format of LIST items retrieved via the NEXT command is the same as
described for the LIST command.
The other valid response from NEXT is when no more documents or List
items are available from the set generated by GETDOCS or LIST. This will
return:
440 No More in Set
The NEXT can return one of the following responses under an error
condition:
400 service discontinued
433 GETDOCS or LIST not performed
434 GETDOCS or LIST returned 0 set
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.7. The QUIT command
The QUIT command is used to tell the server that the client has no more
work to perform, and wishes to terminate the connection. If a client
simply disconnects (or the connection times out, or some other fault
occurs), the server should gracefully cease its attempts to serve the
client.
5.7.1. QUIT
QUIT <CRLF>
5.7.2. Responses
205 closing connection - goodbye!
5.8. The RCPT Command
The RCPT command, like in SMTP, follows the SEND command, and is used to
specify the target address. In the ECTP case, this is the trading
partner id at the server to which the client is currently connected.
This is a conversational model that does not support distribution lists
nor forwarding. Only one RCPT is permitted to be specified.
5.8.1 RCPT
RCPT<SP><To-TradingPartner><CRLF>
5.8.2 Responses to RCPT
If the trading partner identifier is known at the server location, and
if the client has permission to trade with that id, then the server will
respond:
250 OK
It is then the responsibility of the client to send the DATA command to
prep the server for the actual data to be sent.
If the ID to receive the data is unknown or there is a permission
problem on the server, it may respond:
451 Trading Partner ID Unknown
452 Permission to Trade Denied
455 Recipient Already Specified
Otherwise, under an error condition, the server can respond:
400 service discontinued
453 SEND not performed
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.9. The SEND command
The SEND command is used to 'push' a document from the client to the
server. See the DOCUMENT command to (re)retrieve a document made
available to the client. This is the first in the 3-command set of SEND,
RCPT and DATA. Its purpose is to start the sequence, and to specify the
FROM Trading Partner ID.
5.9.1. SEND
SEND <SP> FROM:<Trading Partner ID> <CRLF>
5.9.2. Responses to SEND
If there is no error in the Trading Partner specified, and if there is
no syntax or state problems, the server responds
250 OK
If the ID sending the data is unknown or there is a permission problem
on the server, it may respond:
451 Trading Partner ID Unknown
else it may report an error of type:
400 service discontinued
454 SEND in progress
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
5.10. Command Summary
The complete set of ECTP commands are as follows:
* DATA
* GETDOCS
* HELO
* HELP
* LIST
* NEXT
* QUIT
* RCPT
* SEND
5.11. Minimal Command Implementation
The minimum set of ECTP commands are as follows. Based on the 'Push'
model for data transfer, all retrieval commands are eliminated from the
absolute minimal set. The protocol could operate on the five commands
listed if data is always pushed from client to server; with a new
connection, the client and server reverse roles to move data in the
opposite direction. Enumeration and Retrieval commands are primarily
ways of consolidating operations into a single client-server session.
* DATA
* HELO
* QUIT
* RCPT
* SEND
5.12. Summary of Responses
100 help text
190 through 199 debug output
200 server ready - SEND allowed
201 server ready - no SEND allowed
205 closing connection - goodbye!
210 Document Set Prepared
215 OK - List Follows
216 OK - Partial List Follows
240 Ready to Transfer
250 OK
251 control_number Received OK
354 Ready to Receive
400 service discontinued
430 no such document found
431 Set Empty
433 GETDOCS or LIST not performed
434 GETDOCS or LIST returned 0 set
440 No More in Set
451 Trading Partner ID Unknown
452 Permission to Trade Denied
453 SEND not performed
454 SEND in progress
455 Recipient Already Specified
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed
VI. Author's Address
Kent Schwab Email: kents@actracorp.com
Actra Business Systems Tel#: 1.408.542.3277
610 Caribbean Drive Fax#: 1.408.542.3210
Sunnyvale, CA 94089 USA Visit: http://home.actracorp.com
VII. References
[1] N. Borenstein, "MIME (Multipurpose Internet Mail Extensions) Part
One: Mechanisms for Specifying and Describing the Format of Internet
Message Bodies", RFC 1521, Bellcore, September 1993.
[2] S/MIME is a trademark of RSA Data Security, Inc. No RFC has yet been
issued, but one is expected for Secure Multipurpose Internet Mail
Extensions as soon as interoperability testing is complete.
[3] M. Sirbu, "A Content-Type Header Field for Internet Messages", RFC
1049, CMU, March 1988.
[4] B. Kantor, P. Lapsley, "Network News Transfer Protocol", RFC 977,
U.C. San Diego and Berkeley, February 1986.
[5] J. Postel, "Simple Mail Transfer Protocol", RFC 821, Information
Sciences Institute, University of Southern California, August 1982.
[6] D.H. Croker, "Standard for the Format of ARPA Internet Text
Messages", RFC 822, University of Delaware Dept. of Electrical
Engineering, August 1982.
[7] D. Crocker, "MIME Encapsulation of EDI Objects", RFC 1767,
Brandenburg Consulting, March 1995.
[8] J. Klensin, WG Chair, "SMTP Service Extension for 8bit-
MIME transport", RFC 1426, United Nations University, February 1993.
Appendix A - Alternative Protocol / EC Function Comparison
Requirement SMTP NNTP HTTP FTP
1. Ordered Delivery of Data Objects X
2. Client Can Send and Receive Data Objects X X X
3. Server Data Object Enumeration X X
4. Nexting Support for Data Objects X X
5. Nexting Support for Enumerations (Partial Lists) X X
6. Batch and Conversational Models of Operation
7. Connection-oriented Service with Strong Security X
8. Possible to Record and Audit Individual Activities X* X* X*
9. Possible to Enumerate Services Implemented X X X
10. Documents/Services by User ID X X*
11. Protocol NOT Limited to Specific Appl. Domain X X X
12. Negotiated Possibility to Send to Server at Startup X
* = Implementation-specific Capability
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Brentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------