What I saw at Danvers

This year, my view is becoming even more myopic than usual, since I've been chosen for the post of Area Director for Applications, with a seat on the Internet Engineering Steering Group. This has resulted in a total inability to see anything but two things:

• Applications Area working groups, problems and challenges
• Events and worries that transcend the areas and become topics of discussion in the IESG.

The evolution of IP version 6

A major topic of debate was the requirement of security: as currently written, the IPv6 documents require the implementation of IP packet-layer encryption (Encapsulating Security Payload) and the DES algorithm.
Since this means that under current US laws, IPv6 implementations cannot be shipped overseas without a license, representatives of some US companies made a fuss.
The "will of the community", as expressed in the raising of hands at the open IESG meeting, which is as close as the IETF comes to a general assembly, was completely clear, however: The vast majority wants encryption to be required of IP version 6 implementations. (If anyone wants to sell IPv6-ABE (all but encryption), and consumers want to buy this, that is of course their decision, but the IETF felt that its short labels like IPv6 should not be sold so cheaply)

The World Wide Web

The HTML working group has now completed its "HTML 2.0" document that documents existing practices on the Web (modulo some last minute changes), and should therefore be free to concentrate on "HTML 3.0" or any subsets thereof; there are LOTS of things people want in it, and at the moment there seem to be few voices of caution against the adding of new features.

The HTTP working group is almost ready with its description of the "current practice" protocol HTTP/1.0, and is also gearing up towards the doing of larger things.

The URI working group is now finished with the URL spec, and is now moving from the "the ideal object is" stage to the "will it work?" stage of its Universal Resource Name design. The group did not discuss what character sets should be in an URN! This effort still seems to have some way to go before reaching closure, however.

All in all, it would seem that the Web community is soon in the possession of a solid base of documents that enable it to tell the difference between standard practice, experimental extensions and just sheer bad products on this, the application that is now eating half our network resources.

Electronic mail

The NOTARY group reached closure, giving the Internet a standardized format for telling users that their mail has failed to be delivered for the first time.

And modulo implementation (which is already underway in a number of implementations, including Sendmail), we will even have a means of requesting confirmation of delivery, something the X.400 folks have always been telling us is an essential thing to have when running an E-mail system. Seems that the Internet has managed for a while without it, but it sure can be nice to have....

The decision was also made to let the MIXER group, the redesign of X.400/Internet gatewaying to integrate MIME, wait for the NOTARY work to be included, so that the next generation of X.400 gateways to the Internet can handle delivery notifications in an interworkable manner.

In the discussions on future work, the group decided to recommend the establishing of a working group on receipt notifications and other UA-to-UA messages; miraculously, a document editor and willing, competent working group chairs volunteered immediately!

The MAILEXT group concluded all its work items, modulo the usual set of small nits to be fixed, and requested that almost all its suggested SMTP extensions be published as Experimental standards, with a bit different justifications:

• SMTP Pipelining should go to Proposed; it is simple and should have little impact, and implementations already exist.
• SMTP Checkpoint/Recovery should go to Experimental; there does not seem to be a large interest in the community, but it seems so simple eand well worked out that it deserves to be enshrined.
• SMTP Chunking and Binary should go to Experimental BECAUSE there is great community interest; the impact of possibly badly done downgrading of Binary to 7bit MIME may be great enough to make considerable trouble, and the group felt that experimentation with the protocol in practice was strongly indicated.

The greatest challenge, however, was the decision about the "SMTP applicability statement": The decision was made that rather than continuing to issue RFC after RFC with changes, clarifications and revisions to the original Internet mail RFCs (821 and 822), we should rewrite them into new RFCs that document clearly and concisely existing standard in a single document pair.
Keith Moore was appointed chair of this effort, with John Myers and John Klensin being primary editors for the documents

Directories

Anyway, the progress in the area wrt investigating existing practices and implementations seems satisfactory, while the real development work seems surprisingly quiet.

The ideal of "one Internet, one directory" is still not gone; we still want to have all information available to anyone who asks - but we still don't know how to achieve that goal.

X.500 as a solution is far from dead, too; the time required for WHOIS++ to get from the bar napkin into reality seems to be quite a bit longer than some people expected a few years ago. It might still arise as a serious challenger to X.500, but currently, deployment of X.500 with all its problems seems to outstrip WHOIS++ by a large margin.

However, the "feel" of the field is that there is as of yet no clear road to the universal directory. More's the pity!

Closing words

I know that there is hard and competent work going on with DNS, routing protocols, multicasting, user services (school networking, for instance), security, routing and various other places - but if you want to know what's going on there, you will simply have to ask someone else.

These eyes and ears have only so much to report.