365 RFCs

Commenting on one RFC a day in honor of the 50th anniversary of the first RFC.

by Darius Kazemi, April 10 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A catalog

RFC-100 is titled “Categorization and Guide to NWG/RFCs”. It's by Peggy M. Karp of MITRE and dated February 26th, 1971.

The technical content

This document lists all RFCs to date, first by category, then in numerical order with cross references to the categories for the documents. It's similar to how card catalog systems used to organize documents at libraries, which if you are of a certain age you'll remember using. (I suspect I'm on the cusp and most people younger than me never used these.)

The document offers a “minimum subset of RFCs”, which are basically the must-read RFCs for anyone who wishes to be caught up to NWG discussions as of February 1971. And further, that the list is short enough that it “should dispel any fear of maintaining stacks of NWG/RFCs for quick reference.”

The subset is as follows (links to my own blog posts and their titles):

As well as this very RFC and the next two, 101 and 102.

The categories listed are, broadly:

  • Administrative
  • Host/IMP Protocol (Level 1)
  • Host/Host Protocol (Level 2)
  • Subsystem Level Protocol (Level 3)
  • Measurement of Network
  • Network Experience
  • Site Documentation
  • Accounting
  • Other

Most categories have sub-categories that you can read in the original document.

This document is slated to become part of a separate, non-RFC series of documents, although I'm not sure if that series ever came to pass (there are many more of these catalogs in the RFC series itself over the years).

Analysis

This document is RFC-100 but the author notes at the beginning that there are already 102 RFCs. And indeed, RFCs 101 and 102 are dated three days before this one. I don't know if they simply wanted RFC-100 to be used for this catalog, or if the RFC numbers were assigned prior to the final RFC being sent to the NWG members.

The list of categories is the first official confirmation of levels 1, 2, and 3.

Further reading

The author notes that

reference to “#33, #66, #83, etc.” is a convenient shorthand (reminiscent of the old corny joke about joke #s) used extensively during meetings.

The joke referred goes something like this: a guy goes to prison. He becomes aware of a weird phenomenon where he'll hear someone yell a number like “71!” and people laugh. His bunk mate explains to him that the jokes here are so stale and repetetive that they've just numbered them all to save time. So the guy yells out a random number. At this point the punchline is either: everyone laughs and says “wow we've never heard that one before”, or nobody laughs and the bunkmate says “wow, some guys just are no good at telling jokes.”

I assume the implication here is that attending a Network Working Group meeting is more or less like being in prison.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 9 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Atlantic City again

RFC-99 is titled “Network Meeting”. It's authored by Peggy M. Karp of MITRE. In November 1970 she was appointed the position of RFC editor.

The technical content

As in the previous year, the Network Working Group will meet at the Spring Joint Computer Conference in Atlantic City. Their meeting will be at the historic (and near bankruptcy by 1971) Dennis Hotel. MITRE, via Karp's secretary, is handling the hotel reservations to ensure everyone stays at the same hotel.

The meeting will span the evening of Sunday May 16th through Thursday May 20th. This is about twice as long as their last Network Meeting.

Further reading

By the way! Americans might know Atlantic City as a place for casino gambling (it was at one point essentially the Las Vegas of the east coast). But casino gambling was not legal there until 1976, well after the timeline of these Joint Computer Conferences. In 1971, Atlantic City was primarily known as a resort destination on the beach with huge hotels and the ability to host large business conventions.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 8 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Logging in

RFC-98 is titled “Logger Protocol Proposal”, authored by Edwin W Meyer, Jr. and Thomas P. Skinner of MIT's Project MAC. It's dated February 11, 1971.

The technical content

The authors state that since the Host-Host protocol is at least somewhat “done”, the next step of ARPANET on a software level should be the development of a “logger protocol”. When a programmer today hears “logger” they might think of a program that writes messages to, for example, an error log, which is a log book that you can audit to see what went wrong with a program. This is not what they mean here.

In this paper, a “logger protocol” is meant to define how “log in” to a remote computer. At the time of this RFC, you had to log in to different systems using different mechanisms. The proposal here is trying to make a single mechanism for login (kind of like various flavors of OAuth try to do on the web).

They suggest tackling this kind of system before attempting a file transfer system because they suspect it's simpler to do, and still necessary, so they might as well get it out of the way first before tackling the big problem.

The authors break the login process into three parts:

  1. “Connection phase”, the establishment of an initial connection
  2. “Dialog phase”, for verification that the user has the right to use the system
  3. “Admission phase”, when the program hands off control from the logger to a system process so the user is no longer just talking to the logger

For the connection phase, the authors endorse the one laid out in RFC-80 from Harslem and Heafner of RAND. But the authors of this RFC also note that disconnection is important: the connections and links need to be cleaned up and freed if this occurs for any reason.

Next is the dialog phase, the actual “logging in” part, where you say “I am user X and I would like access to this computer”. The RFC says that there should be a standard character encoding here and that it should probably be ASCII. Dialog occurs in “transaction blocks” which are sets of ASCII characters preceded by a command code (which is always 0), and then a binary integer indicating the number of characters to be expected in the block (0 to 127; the most significant bit is always 0 so it's a 7-bit number). The character length indicator is to get around some of the character-based vs line-based processing issues we continually encounter.

They don't specify anything for the admission phase, and they note that this is probably going to be trivial in a lot of cases.

They end the document on a note about some edge cases.

First they discuss echoplex (not to be confused with the tape delay effect. Most teletype machines, when you pressed a key like A, would simultaneously move the mechanical print head to print “A” on paper and also send A to the computer. A teletype with echoplex would wait until it got confirmation from the computer that it received A before printing “A” on your roll of paper. Logins should not support this, to reduce complexity.

If someone makes a mistake while logging in, they can use “input editing conventions” to fix it, or just abort their connection and restart the login process.

The logger should only allow an idle connection for “perhaps a minute” until dropping the connection.

Under the current scheme the logger would need to assign a local socket before login was complete; it might be useful in future cases to assign a specific local socket during the admission phase, after the user's identity is determined.

Analysis

In addition to the authors' pragmatic reasoning for wanting a login protocol, they also posit that

agreement on a common [login] protocol would tend to foster a sense of Network “community”, which would tend to be fragmented [without a common protocol.]

I haven't seen an assertion like this before in the RFC series and it's an interesting one. It makes sense that it would come from Multicians, whose extremely strong community exists to this day. Sitting here in 2019 it seems almost obvious that common protocols would foster community, but I think the idea would have been far less obvious in 1971.

When discussing disconnection the authors note that when a user disconnects, their associated processes should also stop. This reminds me of modern Unix systems, where disconnecting from an ssh connection will stop your processes unless you specify that they are to be run continuously in your absence via something like nohup.

The recommendation of ASCII for the dialog phase may explain why lots of computers still balk at the idea of having an accented character in a username. Recall that ASCII doesn't support characters like é.

Further reading

Forgive me but I'm about to digress about typography. I believe this is the first RFC chronologically in the RFC Editor site to have its own HTML rendering. Something about the strictly-justified text formatting causes me to suspect it might have been formatted in RUNOFF, which would certainly make sense given that RUNOFF was developed for Multics, and Project MAC was the home of Multics. (By “justified” I mean the number of spaces between words is varied between one and two in order to make the length of each line exactly 72 characters per line, which makes it a “72 CPL” text document. According to Wikipedia many teletypes could print up to but no more than 72 characters per line.)

Dave Walden once again comes to the rescue here with his paper, “An informal look into the history of digital typography”. In it, he references the CTSS Programmer's Guide, written in December 1966, which in its introduction highlights justification as a key RUNOFF feature.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 7 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

A Telnet protocol

RFC-97 is called “A First Cut at a Proposed Telnet Protocol”. It is authored by John T. Melvin and Richard W. Watson of SRI-ARC and dated February 15th, 1971.

In addition to the usual text version of the RFC, there is a scanned PDF version you can read at the official RFC Editor site.

The technical content

If you'll recall, the last formal document on Telnet was RFC-15 way back in September 1969. That RFC proposed something called “Telnet” and loosely described what it did, but was not specific enough to be a formal specification for consistent implementation. As a result, Telnet was implemented in more than one site but in different ways. This RFC is the first attempt to formalize Telnet.

One big thing set out here is that an important convention is to have Telnet itself sit in between the NCP of the Host and what we'd today call I/O (input/output) device interfaces. Basically, from the point of view of computer with Telnet installed on it, Telnet is just another piece of hardware. The computer doesn't care if character messages are coming from Telnet via ARPANET or from a teletype machine hooked up directly to the computer. Similarly, writing to Telnet from a computer should be like writing to a teletype for output. Meanwhile, Telnet is what talks to the NCP. This is laid out in Figure 1:

There will be situations where the user might want to talk directly to the NCP so the authors recommend that direct connection to the NCP from user processes should still be allowed.

The authors establish that instead of using the terms “full/half duplex” for different kinds of connections they will instead talk about “echo control” methods. This is because Telnet connections are all actually full duplex. There will be different command modes for the cases described in previous RFCs with character-at-a-time transmission or line-by-line transmission.

Servers will assume that any remote connections will use the default character set that the server is used to. Control characters and two-character sequences pose a problem. (They still do today in all sorts of computing applications.)

Analysis

Section 3E begins,

The carriage return (CR) character can be the source of considerable difficulty.

This character vexes programmers five decades later and is still the source of countless bugs and even security holes.

Further reading

Here's a history of line ending encoding by Luke Maciak that nicely summarizes all the context around CR/LF, including the role that teletype machines played. I learned from this that there's a reason that carriage return almost always precedes line feed, aka why it's CR/LF and not LF/CR. The reason? Carriage return is the movement of the print/type head from the far right to the far left of the paper and takes a while to happen. Line feed is just scrolling the paper a fraction down so the next line can be printed. Since CR takes longer than LF and both could happen at the same time, by sending a CR/LF command you could get a “free” line feed without having to wait for the carriage return to finish! (On slow teletypes this would make no difference.) Here is a timing diagram with some timings I completely made up but it gets the idea across:

A timing diagram that shows an LF command occurring during the entirety of a CR command, assuming some kind of clock latching the inputs.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 6 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

An experiment

RFC-96 is titled “An Interactive Network Experiment to Study Modes of Access the Network Information Center”. It's authored by Richard W. Watson of the Augmentation Research Center at Stanford Research Institute (SRI-ARC), dated February 12th, 1971.

The technical content

The RFC begins by explaining that SRI-ARC wants to provide network access to services at the Network Information Center. The original SRI-ARC Online System is a graphics-oriented one, and the author notes that they are now developing a “typewriter version”. This is presumably since the network doesn't have a graphics standard yet, though the author does not say so. By “typewriter” he means a teletype or teleprinter, and he recommends one that can print 30 characters per second as a good baseline.

The author proposes a three-month-long experiment to determine the best way to provide the NIC services throughout the network. They'd collect network statistics and subjective impressions of participants.

The paper then goes on to describe some remote connection methods that they want to try out on users. Essentially they want to see what user experience is like when individual ASCII characters are sent as they are typed (and whether this should be full duplex (simutaneous) or half duplex (taking turns)), versus sending a full line/command at a time over the network.

They mention that on the old SRI-UTAH connection it could take up to 4 or 5 seconds for a single character to be transmitted from one Host to the other.

Analysis

This seems like a good test to do.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 5 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Paper

RFC-95 is titled “Distribution of NWG/RFCs Through the NIC”, authored by Steve Crocker on February 4th, 1971.

The technical content

Something that comes up every time I talk to people about this blog is: these RFCs are paper documents sent via the postal service. It's a mailing list, but at this point in time email had not been invented. So all of this was coordinated by secretaries at the various sites maintaining manual distribution lists.

This document notifies people in the Network Working Group that the Network Information Center (NIC) at Stanford Research Institute is going to be taking on a more authoritative role in managing offline communication between ARPANET sites.

This document makes a request that individual ARPANET sites should have a Technical Liaison Contact, who is the main person receiving the physical copies of RFCs. It's their job to notify the right people at their institution of the RFC content, so if something comes in about graphics, the liaison is supposed to notify their local graphics expert.

RFCs will only be sent to these liaisons.

RFC numbers are now being assigned by Jeanne North (aka Reddy Dively). NIC numbers (which is a separate numbering system used by SRI/NIC) are also currently being assigned by her.

If a person at an ARPANET site wishes to distribute an RFC, they can either send a document to North at the NIC, or send it themselves to everyone provided they let North know and get an updated mailing list membership from her.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 4 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Graphics suggestions

RFC-94 is titled “Some Thoughts on Network Graphics”, dated February 3, 1971. It's authored by Eric Harslem and John Heafner, the dynamic duo from RAND who have authored many RFCs to date.

The technical content

This document is a reaction to Steve Crocker's RFC-86, which was a simple drawing format to send over the network. They like the proposal but think it needs to be extended to be able to support drawing more complex objects.

The detailed constraints enumerated in Note 86 restrict many interesting features of the Rand display hardware that we consider necessary (from a human factors standpoint) to some current applications. [...] For example, the point, vector, and character capability of Note 86 excludes line type mode, intensity control, and many other attractive control operations; the maximum symbol sizes are too small for our large character size; the origin of all of our symbols is specified as the “centroid” of the symbol rather than the lower left corner of a virtual rectangle encompassing the symbol; under mode control for plotting purposes, the beam may not be advanced to the next character position; a 7-bit ASCII is insufficient; etc.

They make a few suggestions for a network graphics protocol:

  1. That a detailed survey of the graphics capability of the ARPA nodes be taken and that a union of current and anticipated hardware be supported.
  2. Data structures for images “should allow logical as well as pictorial representation”. I take this to mean that there be room for, essentially, annotation so that you can send logical metadata. So if you are sending a picture of a house as a series of lines, you could send not just LINE(X,Y) but LINE(X,Y, "roof") (syntax is my own pseudocode).
  3. Definitions of graphics should be sent before instances. For example, if you want to draw multiple houses and copy them over and over, the protocol should state that the house “primitive” should be defined and then multiple instances of HOUSE(X,Y). (This is something that Crocker's spec does, but I think the authors are speaking more generally now of what they want from a spec.)
  4. There should be a way to mark out rectangular areas of the screen for processing purposes. For example, you could assign one process to dynamically update one section, and a separate process to update another. Or you could mark a section of an image as static and unchanging. Or assign different sections of an image to different CRT monitors.
  5. They push their data reconfiguration language from RFC-83 as a way to do stuff like transform image data for file compression targets in addition to the obvious usage of monitor display targets.

They then suggest a completely different approach to RFC-86:

An alternative approach is to consider the situation of communication between non-minimal nodes (nodes with substantial memory and computing power).

They suggest that if an underpowered terminal connects to a remote machine with more capablity than the underpowered terminal, “the connection is invalid. A terminal should NORMALLY only connect to a program that addresses no more than its hardware capabilities.”

They also suggest a third network node that is an intermediary between the powerful graphical terminal a weaker terminal. This intermediary node would provide RFC-83 style data reconfiguration services and they tag this as an “essential part of this proposal”. Here's the network topology that they illustrate in Figure 2:

A network topology diagram showing a reconfiguration service linking two hosts.

Analysis

I don't like this proposal. I think it misses the point of having a minimal protocol with maximal compatibility. There should be a protocol like Crocker's, which then maybe has a higher level protocol on top of it that the big beefy graphics machines can use to talk to one another if they so wish. They also seem to be stretching to find uses for their data reconfiguration language. I actually really like their language but I think this is not the best place to push for it.

It also seems a little unnecessarily combative, to the point where they are missing details. I think they they missed the portion of Crocker's RFC which states that the NGLI would support primitives for intensity.

Anyway, Crocker's position is “let's crawl before we can walk and support a minimum set of maximally compatible features across the network”, whereas the RAND folks want their fancy features supported.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 3 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Code zero

RFC-93 is titled “Initial Connection Protocol”. It's authored by Alex McKenzie of BBN, dated January 1971 (no day of month).

The technical content

This RFC points out an ambiguity in RFC-66 and RFC-80. There is a control message sent during the initial connection “defined as 'exactly an even 32 bit number'”. It's unclear what the message type code for this message is supposed to be. This is kind of amusing because there is only one message type code currently defined (code zero), but they want things to be as clear as possible in case further message type codes are defined in the future. They suggest amending the intitial connection protocol to specify that it is, indeed, code zero.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 2 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Not issued

RFC-92 was not issued.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.

by Darius Kazemi, April 1 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Thinking about users

RFC-91 is titled “A Proposed User-User Protocol”. It's dated December 27th, 1970 (so, chronologically before our last few RFCs) and authored by George H. Mealy of Harvard University.

The technical content

The RFC begins with a problem statement: namely, that the network interface has thus far been treated like generic I/O. This is inconvenient when you have no idea what is on the other side of the I/O though, as different operating systems have wildly different underlying concepts. If you're talking to another computer running the same OS over the network then it makes things really really easy to treat the network as generic I/O, but not so much when there is a mismatch.

The author proposes a User-User protocol that sits on top of the Host-Host protocol. Where the Host-Host protocol deals in messages, the User-User protocol deals in logical records.

Our point of view is that a link is a carrier of information. Information is carried in segments of a fixed maximum length called messages. That this is so is an accident, from the user's point of view; when he wishes to transmit a contiguous stream of data, he will in general, segment it in a different (from the IMP-IMP or HOST-HOST protocol view) manner — we will call his segment a record.

Basically, the user cares to do something like “write a file to the remote computer”, whereas the Host-Host protocol only wants to know about a stream of segmented messages. Mealy wants a protocol that operates on a more “human” level but has interoperability between wildly different operating systems.

There follows a protocol description but I think the more important part of this RFC is the philosophical bit at the beginnging.

Analysis

I think what Mealy is proposing here will eventually become FTP, the File Transfer Protocol. A file is a kind of logical record, and there was much effort put into FTP to make it into something that would work on all sorts of computers. In this 2014 interview with Bob Braden, he says

the IBM had a truly baroque file system, and we wanted to let customers have access to some of the features of it, whereas all the other systems were UNIX systems with a very simple file structure. So if you look at the FTP spec there’s some weirdness, complexity that’s there because I asked for it.

The “IBM” that he's referring to is the exact IBM computer that Mealy references in his intro to this RFC: the IBM 360. I don't think this is a coincidence. Mealy clearly wanted to be able to send files (or something like files) back and forth between a PDP-10 and an IBM 360.

Mealy writes in one of those collegial, casual, Feynman-esque academic styles. In some places his breezy style is really endearing.

ESC is intended as a (hopefully) unused escape hatch, for nonuse by those installations and/or applications wishing to avoid using more than four bits of the USER-USER protocol on any link. For instance, it may be desired to use a link as a bit stream, ignoring even message boundaries. If and when anarchists can achieve local agreement, more power to them!

And later:

The practical questions of implementation are something else! In the case of the PDP-10, I can pretty well see how to turn a SYS into either a LOGON request to execute a monitor command or UUO (would that they were the same) as the case might be. OS/360 is more sophisticated, unfortunately. MULTICS might make it. Naytheless, I hope that is clear that what we want to do, which is what the proto col should reflect, is quite a different question from that of how it is to be done in the context of a specific HOST system.

There is some casual sexism in this RFC, also recalling Feynman. Mealy proposes that bit flags in the protocol that are followed by data blocks be called “block flags”, and other flags be called “whyte flags”. The curious term “whyte” is footnoted as follows:

In memory of an attractive, but nonspelling, SDC secretary who could not distinguish between black and white, at least during 1957 and in manuscript form.

It's basically a bimbo joke. He could have left out “attractive” and this joke would have transitioned state from “creepy” to “mildly amusing”.

Further reading

George H. Mealy invented the Mealy machine, which is not a literal machine but a mathematical construct called a “finite state machine”, which is basically a kind of algorithmic yes/no decision flow chart that a computer or even a physical machine can be constructed to make. Mealy machines are taught widely in electrical engineering programs (or at least they were in the 2000s when I last took an engineering class). For the nerds: it's a type of state machine where the current output is dependent on both the current state and the value of all its inputs. It's an “unsafe” machine where unless you latch your inputs you can change output mid-clock cycle and end up with some nasty edge cases.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.