GRID introduction

GRID computing is becoming more and more important in both computer science community and theoretic science community. Traditional science fields (physics, biology...) have huge amount of data to be processed so that computer resources owned by a single organization can not satisfy the requirements. So grid computing was come up with to solve the problem.

Currently, most promising grid middleware includes: Globus, GLite, Unicore, Crown, (OpenPBS, LSF).
Condor is also a good distributed computing project which is widely used.
Globus is based on OGSA(Open Grid Services Architecture).

OMII-Europe aims to provide key software componenets for building e-inforastructure. Currently, it focuses on providing common interfaces and integration of major Grid software infrastructures. Its goals include interoperability of gLite/UNICORE/Globus/CROWNgrid.

ProActive is an Open Source Java library (LGPL) for parallel, distributed, and multi-threaded computing, also featuring mobility and security in a uniform framework. With a reduced set of simple primitives, ProActive provides a comprehensive toolkit that simplifies the programming of applications distributed on Local Area Networks (LANs), Clusters, Internet Grids and Peer-to-Peer Intranets.
ProActive deploys applications seamlessly on Local Area Networks (LANs), Wide Area Network (WAN), desktops, clusters, parallel machines, and data-centers, using de facto industry standards such as LSF, PBS, Globus and Unicore, or just ssh. ProActive does not require intrusive installation and enterprise IT infrastructure to be modified.

How to find the RFC document you want

RFC3700 defines the Internet Official Protocol Standards which lists all the RFC documents. By searching in this document, you can find the RFC document you want.

Email - POP3

Post Office Protocol3 is defined in RFC 1939. RFC 2249 defines extension to RFC 1939.
Default port is 110.
Request:
Commands in the POP3 consist of a case-insensitive keyword, possibly followed by one or more arguments. All commands are terminated by a CRLF pair. Keywords and arguments consist of printable ASCII characters. Keywords and arguments are each separated by a single SPACE character. Keywords are three or four characters long. Each argument may be up to 40 characters long.
Response
Responses in the POP3 consist of a status indicator and a keyword possibly followed by additional information. All responses are terminated by a CRLF pair. Responses may be up to 512 characters long, including the terminating CRLF. There are currently two status indicators: positive ("+OK") and negative ("-ERR"). Servers MUST send the "+OK" and "-ERR" in upper case.
Life Cycle
A POP3 session progresses through a number of states during its lifetime. Once the TCP connection has been opened and the POP3 server has sent the greeting, the session enters the AUTHORIZATION state. In this state, the client must identify itself to the POP3 server. Once the client has successfully done this, the server acquires resources associated with the client's maildrop, and the session enters the TRANSACTION state. In this state, the client requests actions on the part of the POP3 server. When the client has issued the QUIT command, the session enters the UPDATE state. In this state, the POP3 server releases any resources acquired during the TRANSACTION state and says goodbye. The TCP connection is then closed.
AUTHORIZATION
Once the TCP connection has been opened by a POP3 client, the POP3 server issues a one line greeting. This can be any positive response. An example might be:
S: +OK POP3 server ready
The POP3 session is now in the AUTHORIZATION state. The client must now identify and authenticate itself to the POP3 server. Two possible mechanisms for doing this are described in this document, the USER and PASS command combination and the APOP command.
TRANSACTION
Commands:

STAT

The POP3 server issues a positive response with a line containing information for the maildrop. This line is called a "drop listing" for that maildrop. The positive response consists of "+OK" followed by a single space, the number of messages in the maildrop, a single space, and the size of the maildrop in octets. This memo makes no requirement on what follows the maildrop size.
Examples:
     C: STAT
     S: +OK 2 320

LIST [msg]

Argument: a message-number (optional), which, if present, may NOT refer to a message marked as deleted. If an argument was given and the POP3 server issues a positive response with a line containing information for that message. This line is called a "scan listing" for that message.
If no argument was given and the POP3 server issues a positive response, then the response given is multi-line. After the initial +OK, for each message in the maildrop, the POP3 server responds with a line containing
information for that message. This line is also called a "scan listing" for that message.
Examples:

C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
...
C: LIST 2
S: +OK 2 200
... C: LIST 3
S: -ERR no such message, only 2 messages in maildrop

RETR msg

If the POP3 server issues a positive response, then the response given is multi-line. After the initial +OK, the POP3 server sends the message corresponding to the given message-number, being careful to byte-stuff the termination character (as with all multi-line responses).
Example:
Examples:
C: RETR 1
S: +OK 120 octets
S:
S: .

DELE msg

The POP3 server marks the message as deleted. Any future reference to the message-number associated with the message in a POP3 command generates an error. The POP3 server does not actually delete the message until the POP3 session enters the UPDATE state.
Examples:
C: DELE 1
S: +OK message 1 deleted
...
C: DELE 2
S: -ERR message 2 already deleted

NOOP

The POP3 server does nothing, it merely replies with a positive response.

RSET

If any messages have been marked as deleted by the POP3 server, they are unmarked. The POP3 server then replies with a positive response.

UPDATE
When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state. (Note that if the client issues the QUIT command from the AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE state.)

QUIT

The POP3 server removes all messages marked as deleted from the maildrop and replies as to the status of this operation.

Optional Commands

TOP msg n

return top n lines in mail msg.

UIDL

It is called a "unique-id listing" for that message. A unique-id listing consists of the message-number of the message, followed by a single space and the unique-id of the message. No information follows the unique-id in the unique-id listing.

USER name

To authenticate using the USER and PASS command combination, the client must first issue the USER command.

APOP name digest.

A POP3 server which implements the APOP command will include a timestamp in its banner greeting. The syntax of the timestamp corresponds to the `msg-id' in [RFC822], and MUST be different each time the POP3 server issues a banner greeting.

Email and MIME(4): MIME type specification

RFC 2046. Multipart: mixed: alternative:

Email and MIME(5): Canonical model

RFC2049

Email and MIME(3): message header extension

RFC 2047. In previous RFC document, the values of field name and field body are limited to US Ansi characters. The extension to message headers allows users to use their own language(e.g. Chinese) as values of headers. More detail is in RFC 2047. An 'encoded-word' is defined by the following ABNF grammar: encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; see section 3 encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<Any printable ASCII character other than "?" or SPACE> ; (but see "Use of encoded-words in message ; headers", section 5) The "?" character is used within an 'encoded-word' to separate the various portions of the 'encoded-word' from one another, and thus cannot appear in the 'encoded-text' portion. An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word's is limited to 76 characters. unencoded white space characters (such as SPACE and HTAB) are FORBIDDEN within an 'encoded-word'. For example, the character sequence =?iso-8859-1?q?this is some text?= would be parsed as four 'atom's, rather than as a single 'atom' (by an RFC 822 parser) or 'encoded-word' (by a parser which understands 'encoded-words'). The correct way to encode the string "this is some text" is to encode the SPACE characters as well, e.g. =?iso-8859-1?q?this=20is=20some=20text?= These are the ONLY locations where an 'encoded-word' may appear. In particular: + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'. + An 'encoded-word' MUST NOT appear within a 'quoted-string'. + An 'encoded-word' MUST NOT be used in a Received header field. + An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'. Initially, the legal values for "encoding" are "Q" and "B". These encodings are described below. The "Q" encoding is recommended for use when most of the characters to be encoded are in the ASCII character set; otherwise, the "B" encoding should be used.

Email and MIME(2)

To support non-English languages and transmission of non-text data(image, video clip...), MIME is defined(RFC 2045 through RFC 1049).
Several more headers are added beyond those defined in RFC 2822:
(1) A MIME-Version header field, which uses a version
number to declare a message to be conformant with MIME
and allows mail processing agents to distinguish
between such messages and those generated by older or
non-conformant software, which are presumed to lack
such a field.

(2) A Content-Type header field, generalized from RFC 1049,
which can be used to specify the media type and subtype
of data in the body of a message and to fully specify
the native representation (canonical form) of such
data.

(3) A Content-Transfer-Encoding header field, which can be
used to specify both the encoding transformation that
was applied to the body and the domain of the result.
Encoding transformations other than the identity
transformation are usually applied to data in order to
allow it to pass through mail transport mechanisms
which may have data or character set limitations.

(4) Two additional header fields that can be used to
further describe the data in a body, the Content-ID and
Content-Description header fields.

Data type:

7bit Data
"7bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]. No octets with decimal values greater than 127
are allowed and neither are NULs (octets with decimal value 0). CR
(decimal value 13) and LF (decimal value 10) octets only occur as
part of CRLF line separation sequences.

8bit Data
"8bit data" refers to data that is all represented as relatively
short lines with 998 octets or less between CRLF line separation
sequences [RFC-821]), but octets with decimal values greater than 127
may be used. As with "7bit data" CR and LF octets only occur as part
of CRLF line separation sequences and no NULs are allowed.

Binary Data
"Binary data" refers to data where any sequence of octets whatsoever
is allowed.

Formal Description of MIME headers:

entity-headers := [ content CRLF ][ encoding CRLF ][ id CRLF ][ description CRLF ]*( MIME-extension-field CRLF )

MIME-message-headers := entity-headers fields
version CRLF
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.

MIME-part-headers := entity-headers[ fields ]
; Any field not beginning with
; "content-" can have no defined
; meaning and may be ignored.
; The ordering of the header
; fields implied by this BNF
; definition should be ignored.

Header explanation

MIME-Version:
For example:MIME-Version: 1.0
Note that the MIME-Version header field is required at the top level of a message. It is not required for each body part of a multipart entity. It is required for the embedded headers of a body of type "message/rfc822" or "message/partial" if and only if the embedded message is itself claimed to be MIME-conformant.
It is also worth noting that version control for specific media types is not accomplished using the MIME-Version mechanism. In particular, some formats (such as application/postscript) have version numbering conventions that are internal to the media format. Where such conventions exist, MIME does nothing to supersede them. Where no such conventions exist, a MIME media type might use a "version" parameter in the content-type field if necessary.
Content-Type
The Content-Type header field specifies the nature of the data in the body of an entity by giving media type and subtype identifiers, and by providing auxiliary information that may be required for certain media types. After the media type and subtype names, the remainder of the header field is simply a set of parameters, specified in an attribute=value notation. The ordering of parameters is not significant. The set of meaningful parameters depends on the media type and subtype.
For example, the "charset" parameter is applicable to any subtype of "text", while the "boundary" parameter is required for any subtype of the "multipart" media type.
If another top-level type is to be used for any reason, it must be given a name starting with "X-" to indicate its non-standard status and to avoid a potential conflict with a future official name.
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.

type := discrete-type / composite-type

discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token

composite-type := "message" / "multipart" / extension-token

extension-token := ietf-token / x-token

lt;ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>

x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>

parameter := attribute "=" value

attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>

tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
Note that the value of a quoted string parameter does not include the quotes. That is, the quotation marks in a quoted-string are not a part of the value of the parameter, but are merely used to delimit that parameter value.
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
are the equivalent.
If no Content-Type header field is specified, default setting is:
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding
encoding := "Content-Transfer-Encoding" ":" mechanism
mechanism := "7bit" / "8bit" / "binary" /"quoted-printable" / "base64" /ietf-token / x-token
Default value is: 7bit.
Three transformations are currently defined: identity, the "quoted-printable" encoding, and the "base64" encoding. The domains are "binary", "8bit" and "7bit".
The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed. As such, they serve simply as indicators of the domain of the body data, and provide useful information about the sort of encoding that might be needed for transmission in a given transport system.
Implementors may, if necessary, define private Content-Transfer-Encoding values, but must use an x-token, which is a name prefixed by "X-", to indicate its non-standard status, e.g., "Content-Transfer- Encoding: x-my-new-encoding".
Currently the only composite media types are "multipart" and "message". All encodings that are desired for bodies of type multipart or message must be done at the innermost level, by encoding the actual body that needs to be encoded. In other words, recursive encoding is not allowed.
Content-ID
syntactically
identical to the "Message-ID" header field:
id := "Content-ID" ":" msg-id
Like the Message-ID values, Content-ID values must be generated to be world-unique.
Content-Description
simple content description

All MIME headers:

MIME-Version
Content-ID
Content-Description
Content-Transfer-Encoding
Content-Type
Content-Base
Content-Location
Content-features
Content-Disposition
Content-Language
Content-Alternative
Content-MD5
Content-Duration