39a40,42
>                   3.2.2.1. Proposed
>                   3.2.2.2. Accepted
>                   3.2.2.3. Rejected
63,65c66,69
<            6.1.1. 200 OK
<            6.1.2. 250 (session initiation)
<            6.1.3. 260 (session termination)
---
>            6.1.1. 200 OK (general)
>            6.1.2. 201 OK (GET)
>            6.1.3. 250 (session initiation)
>            6.1.4. 260 (session termination)
67,69c71,75
<            6.2.1. 401 System Resource Failure
<            6.2.2. 402 Address Mismatch
<            6.3.3. 403 Size Limit Exceeded
---
>            6.2.1. 400 Bad Request
>            6.2.2. 401 System Resource Failure
>            6.2.3. 402 No Match Found
>            6.2.4. 403 Size Limit Exceeded
>            6.2.5. 405 Not Permitted in Current State
81c87
<    e-Parcel is intended to address the problems encountered when
---
>    The e-Parcel protocol is intended to address the problems encountered when
83,86c89,94
<    The e-Parcel Protocol enables the exchange of arbitrary length attachments,
<    using the recipient's e-mail address.  The protocol allows the
<    recipient to either accept or reject delivery of the attachment.  A
<    description of the attachment is provided to the recipient by including
---
>    The e-Parcel protocol enables the exchange of arbitrary length attachments,
>    using a recipient identifier (which may be the same as the recipient's 
>    e-mail address).  
>    The protocol allows the recipient to either accept or reject delivery of the 
>    attachment.  
>    A description of the attachment is provided to the recipient by including
88c96
<    If the transfer is not accepted, then no transmission of the attachment
---
>    If the transfer is rejected, then no transmission of the attachment
95c103
<    from e-mail (e.g., [1]).
---
>    from SMTP [1].
120,123c128,130
<       A program that establishes connections for the purpose of sending
<       requests in cooperation with an e-Parcel server. 
<       A local language may be used in the user interface command/reply 
<       dialogue. The client initiates e-Parcel commands, receives replies, and 
---
>       An application program that establishes connections for the purpose of 
>       sending requests in cooperation with an e-Parcel server. 
>       The client initiates e-Parcel commands, receives replies, and 
124a132,133
>       A local language may be used in the user interface command/reply 
>       dialogue. 
129c138
<       It transfers mail in cooperation with a e-Parcel client.
---
>       It transfers messages and files in cooperation with an e-Parcel client.
134,137c143,147
<    reply 
<       A reply is an acknowledgment (positive or negative) sent from the server
<       to the client via the transmission channel in response to a command. The 
<       general form of a reply is a completion code (including error codes) 
---
>    reply or response
>       A reply (or response) is an acknowledgment (positive or negative) sent 
>       from the server to the client via the transmission channel in response 
>       to a command. 
>       The general form of a reply is a completion code (including error codes) 
142,143c152,153
<      The short description of the file or attachment to be sent to the 
<      recipient.
---
>      An XML [6] document containing a short description of the file or 
>      attachment to be sent to the recipient.
148a159,162
>    approval/refusal message
>      After the recipients approves for receiving the attachment, the e-parcel 
>      client will generate an approval/refusal message similar to e-stub.
> 
150c164
<      A a sequence of ASCII characters ending with a <CRLF>. 
---
>      A sequence of ASCII characters ending with a <CRLF>. 
166c180
<    as the recipient address and the size of the attachment.
---
>    as the recipient address, the file name, and the size of the attachment.
185,186c199,200
<    RFC 2616 [5]. Refer to [5] for the definition
<    of terms such as TEXT, HEX, mailbox, and host. 
---
>    RFC 2616 [5]. 
>    Refer to [5] for the definition of terms such as mailbox and host. 
243c257
<    the definition of mailbox in RFC 822 [4] as updated by RFC 1123 [10].
---
>    definition of mailbox in RFC 822 [4] as updated by RFC 1123 [10].
249c263
<    An e-parcel stub is a well-formed XML document.
---
>    An e-Parcel stub (e-Stub) is a well-formed XML document [6].
251,253c265,267
<    <etag> element, one <from> element, at least one <to> element, one
<    <filesize>, and one <state>. 
<    Additionally, a <stub> MAY contain a <filename>,
---
>    <filename> element, one <etag> element, one <from> element, 
>    one <to> element, one <filesize> element, and one <state> element. 
>    Additionally, a <stub> MAY contain 
255a270,271
>    Elements which do not appear in this document should have an appropriate
>    XML namespace to distinguish them from extensions introduced by others.
259,260c275,276
<        <?xml version="1.0"?>
<        <stub>
---
>        <?xml version="1.0" encoding="us-ascii"?>
>        <stub version=0.1>
264d279
<          <to>eecs423@eecs.cwru.edu</to>
280c295,296
<    The client is REQUIRED to provide an alphanumeric tag (e-tag) that 
---
>    The client is REQUIRED to provide a tag (e-tag) that consists
>    of alphanumeric characters and the dash ("-") character and that
287,288c303,319
<    The e-Stub state can take one of the values "proposed", "accepted",
<    or "denied".
---
>    The e-Stub state MUST contain one of the values "proposed", "accepted",
>    or "rejected".
> 
> 3.2.2.1 Proposed
>    The state of an e-Stub when it has been generated by the sending
>    client.  This state indicates that the e-Stub is still awaiting
>    action by the receiving client.
> 
> 3.2.2.2 Accepted
>    The state of an e-Stub when it has been reviewed by the receiving
>    client, and the receiving client has chosen to approve the delivery 
>    of the file described in the e-Stub.
> 
> 3.2.2.3 Rejected
>    The state of an e-Stub when it has been reviewed by the receiving
>    client, and the receiving client has chosen to not approve the delivery 
>    of the file described in the e-Stub.
291,292c322,323
<    The <from> and <to> elements represent the mailbox of the sending and
<    receiving users.
---
>    The <from> and <to> elements MUST contain the mailbox of the sending and
>    receiving users, respectively.
306,309c337,343
<    A short digest of the file supports integrity checks. The <digest> element
<    MUST contain a <type> (e.g., MD5 to denote an MD5 digest [11]) and 
<    a <value> (the file digest).
<    
---
>    A short digest of the file supports integrity checks. 
>    The <digest> element MUST contain a <type> (specifying the digest algorithm
>    used) and a <value> (the file digest). The <type> element MAY take on the 
>    values "MD5" and "SHA1" to specify the MD5 [11] and SHA1 algorithms, 
>    respectively. The <type> element MAY also take on other values to indicate 
>    alternative algorithms, as agreed upon by the Internet community.
> 
312,313c346,347
<      An e-Stub list is a well-formed XML documents whose root is <stublist>
<      and its elements are <stub>s.
---
>      An e-Stub list is a well-formed XML document whose root is <stublist>
>      and whose elements are <stub>s.
317,318c351,353
<    An e-Stub reference is similar to an e-Stub, but its root is <stubref>
<    and it MUST contain only the <from> and <etag> elements.
---
>    An e-Stub reference is a well-formed XML document similar to an e-Stub, 
>    but its root is <stubref> and it MUST contain only the <from> and <etag> 
>    elements.
323c358,359
<    be specified at a later date.
---
>    be specified at a later date. The schemas will implicitly define the
>    rules for eStub, eStubRef, and eStubList.
331c367
<    Each request or reponse is conveyed in a message.
---
>    Each request or response is conveyed in a message.
338c374
<                     GET-REQUEST) CRLF) | 
---
>                     GET-REQUEST) SP Version CRLF) | 
342,346c378,382
<                     MAIL-REQUEST) CRLF Body))
<        Response = ("200" SP Explanation CRLF [Body] |
<                    "250" SP host CRLF |
<                    StatusCode SP Explanation CRLF)
<        StatusCode = "260" | "401" | "402" | "403"
---
>                     MAIL-REQUEST) SP Version CRLF Body))
>        Response = ("201" SP Version SP Explanation CRLF Body |
>                    "250" SP Version SP host CRLF |
>                    StatusCode SP Version SP Explanation CRLF)
>        StatusCode = "200" | "260" | "401" | "402" | "403" | "405"
347a384
>        Version = "EPP/0.1"
351c388
<        Body = eStub | eStubRef | eStubList
---
>        Body = (eStub | eStubRef | eStubList) CRLF "&" CRLF
362c399
<    An e-Parcel sessions is terminated when a client sends an appropriate
---
>    An e-Parcel session is terminated when a client sends an appropriate
366,367c403,404
<    A client MUST start a session with an HELLO command followed by 
<    a fully qualified hostname
---
>    A client MUST start a session with a HELLO command followed by 
>    a client hostname (which SHOULD be fully qualified if possible).
373,374c410
<    server. The HELLO command argument field MUST contain a host name of the 
<    sender client.
---
>    server. 
378,379c414,415
<        C: HELLO bender.cwru.edu
<        S: 250 zoidberg.cwru.edu
---
>        C: HELLO bender.cwru.edu EPP/0.1
>        S: 250 EPP/0.1 zoidberg.cwru.edu
390,391c426,428
<    The server SHOULD NOT close the transmission channel until it receives and 
<    replies to a QUIT command (even if there was an error). 
---
>    The server MUST close the transmission channel immediately after replying
>    to a QUIT command. Either end-point MAY close or reset the connection
>    asynchronously, for example, if the connection has been idle for too long.
411,412c448,449
<      C: MAIL
<      C: <?xml version="1.0"?>
---
>      C: MAIL EPP/0.1
>      C: <?xml version="1.0" encoding="us-ascii"?>
424c461,462
<      S: 200 OK, Requested Action Completed
---
>      C: &
>      S: 200 EPP/0.1 OK
428c466
<      S: 401 System Resource Failure
---
>      S: 401 EPP/0.1 System Resource Failure
436c474
<    The DELETE-COMMAND MUST be followed by a request Body that is an e-Stub or 
---
>    The DELETE-COMMAND MUST be followed by a request Body that is 
438,439c476,478
<    If the server replies with code 200, it MUST delete the e-Stub before
<    replying.
---
>    If the server replies with code 200, it MUST delete, before replying,
>    the e-Stub that has matching <etag> and <from> fields with the 
>    e-Stub reference.
441a481,482
>    If the e-mail address is not the sender of the e-Stub, the server MUST
>    respond with a 402 reply.
450,452c491,493
<    If the server generates a 200 reply, it SHOULD include in the body
<    a list containing all the e-Stubs that are recorded at the server and that 
<    include the given e-mail address in the <from> or <to> record but
---
>    If the server generates a 201 reply, it SHOULD include in the body
>    an e-Stub list containing all the e-Stubs that are recorded at the server 
>    and that include the given e-mail address in the <from> or <to> record but
457c498
< 5.4. Acceptance or Rejection
---
> 5.4. Acceptance and Rejection
465,471c506,515
<    The command MUST be followed in the Body by an e-Stub or an e-Stub 
<    reference.
< 
<    If the e-mail address is not the recepient of the e-Stub, the server MUST
<    respond with a 402 reply.
<    If the server replies with code 200, it MUST change the state to "accepted"
<    before replying.
---
>    The command MUST be followed in the Body by an e-Stub reference.
>    The e-Stub reference will contain the name of the sender and the e-tag.
>    If the <from> and <etag> fields of the e-tag reference match that of 
>    an e-Stub on the server, the mailbox matches the <to> field of 
>    the e-Stub, and the e-Stub is "proposed", the server MUST change the state 
>    of the e-stub to "accepted" and then respond to the client with code 200.
>    If the addresses and e-tags do not match up, the server MUST respond with a 
>    402 reply.
>    If the addresses and e-tag do match up, but the e-Stub is not "proposed",
>    the server must respond with a 405 reply.
482,488c526,535
<    The command MUST be followed in the Body by an e-Stub or an e-Stub 
<    reference.
< 
<    If the e-mail address is not the recepient of the e-Stub, the server MUST
<    respond with StatusCode "402". 
<    If the server replies with code 200, it MUST change the state to "rejected"
<    before replying.
---
>    The command MUST be followed in the Body by an e-Stub reference.
>    The e-Stub reference will contain the name of the sender and the e-tag.
>    If the <from> and <etag> fields of the e-Stub reference match that of an
>    e-Stub on the server, the mailbox matches the <to> field of the e-Stub,
>    and the e-Stub is "proposed", the server MUST change the state of the 
>    e-Stub to "rejected" and then respond to the client with code 200.
>    If the addresses and e-tag do not match up, the server MUST respond with a 
>    402 reply.
>    If the addresses and e-tag do match up, but the e-Stub is not "proposed",
>    the server must respond with a 405 reply.
492a540
> 
498c546
< 6.1.1. 200 OK
---
> 6.1.1. 200 OK (general)
500,502c548,553
<    The 200 response MUST NOT be used as a reply to HELLO or QUIT.
<    The server MUST NOT include a response Body unless 200 is in reply
<    to a GET command.
---
>    The 200 response MUST NOT be used as a reply to HELLO, QUIT, or GET.
> 
> 6.1.2. 201 OK (GET)
>    The GET command succeeded and an eStubList is being returned in the
>    body of the reply. A suggested Explanation is "OK".
>    The 201 response MUST NOT be used as a reply to any command but GET.
504c555
< 6.1.2. 250 (session initiation)
---
> 6.1.3. 250 (session initiation)
510c561
< 6.1.3. 260 (session termination)
---
> 6.1.4. 260 (session termination)
517c568,572
< 6.2.1. 401 System Resource Failure
---
> 6.2.1. 400 Bad Request
>    The request could not be understood by the server due to malformed syntax. 
>    The client SHOULD NOT repeat the request without modifications.
> 
> 6.2.2. 401 System Resource Failure
522,525c577,580
< 6.2.2. 402 Address Mismatch
<    The server MUST reply with a 402 response if it cannot complete the request 
<    due to a mismatch between an e-Stub and the mailbox supplied by the client.
<    A suggested Explanation is "Address Mismatch".
---
> 6.2.3. 402 No Match Found
>    The server MUST reply with a 402 response if the e-Stub reference supplied
>    by the client does not match any e-Stub on the server
>    A suggested Explanation is "No Match Found".
528c583
< 6.3.3. 403 Size Limit Exceeded
---
> 6.2.4. 403 Size Limit Exceeded
532a588,592
> 6.2.5. 405 Not Permitted in Current State
>    The server MUST send a 405 reply if the operation is not permitted in 
>    the current state of the e-Stub.
>    A suggested Explanation is "Not Permitted in Current State".
> 
542c602
<    E-Parcel can communicate between processes using different transport
---
>    E-Parcel can communicate between processes using different transports
548,550c608
<    The sender SHOULD NOT close the transmission channel until it send a QUIT 
<    command and receives the reply (even if there was an error response to a 
<    previous command). If the connection is closed prematurely the server 
---
>    If the connection is closed prematurely the server 
560,561c618,619
<    - The maximum total length of a <from> and <to> record is 256 characters 
<      (including punctuation and element separators).
---
>    - The maximum total length of a <from>, <to>, and <filename> records 
>      is 256 characters (including punctuation and element separators).
568c626,630
<    - The maximum total length of an e-Stub MUST NOT exceed 65536 characters.
---
>    - The maximum total length of an e-Stub is 65536 characters.
>    - The maximum total length of an e-stub reference is 1024 OCTETs.
>    - The maximum total length of an etag is 512 OCTETS.
>    - The maximum total length of a mailbox is 256 OCTETs 
>      (including all punctuation and element separators)