By Jacob Palme, e-mail: jpalme@dsv.su.se, at the research group for CMC (Computer Mediated Communication) in the Department of Computer and Systems Sciences at Stockholm University and KTH.
These are my personal notes from some of the application layer sessions, not any official minutes.
The travel costs to this meeting was partly financed by the European Union, Telematics for Research sector.
Security is the buzzword in the Internet today. Earlier, there were special security working groups, now security is handled as an important part of groups handling wider issues than only security. The big competition in security is between PGP and S/MIME. Standards people tend to like PGP because it is open and free, but commercial implementors tend to choose S/MIME.
As always for IETF meetings, I am really impressed by the intelligence and competence of the people who go to these meetings. (With a few exceptions, of course.) Also, as usual, people, though very technically competent, are sometimes not so good at understanding user needs.
The calendaring and scheduling working group (CalSch) is developing a protocol for exchanging calendaring objects over the net. Calendaring objects are events, to do-items, alarms, time zones, freebusy and journals. The primary object is the event, which has a start time, a description, and a duration. Collections of event objects are called calendars. "freebusy" is an object giving information about when a particular person or other bookable object is available or occupied.
These objects are exchanged between calendar users and calendar services.
Protocols defined are called iCalendar, iRIP, iTIP and iMIP. iRIP is the transport independent protocol, iTIP is a session-oriented implementation if iRIP, iMIP is an e-mail based implementation of iRIP.
The work has gone on for one year, and is now in stages of resolving the final problems before submitting the protocols to the IESG for processing.
If you believed that time zones are simple and easy to understand objects, you are wrong. This is a very difficult and complex problem which the calendaring and scheduling work group has not been able to resolve in one year.
The problem is the following: Suppose an event is scheduled to occur at 9:00, Norwegian time. And suppose that after the event was scheduled, the Norwegian Parliament decides to adopt daylight saving time, so that 9:00 Norwegian time is shifted one hour. How should this change be propagated to people who are accessing this event!
Their current description is muddled on how and when to use them, said area director Keith Moore, and several other people agreed. The coupling of times in a particular time zone to UST changes usually twice a year, and these changeover dates are politically determined and sometimes change at short notice. Software should not be written to assume certain fixed dates for changes between daylight saving time and normal time. Example: If a meeting is planned to start at 9:00 a.m. and then the politicians change the changeover date, this should normally not mean that the meetings is moved to 8:00 or 10:00.
This requires a registry of time zone names. A time zone is not a number like "+0:00", it is a description of two time offsets and two yearly changeover dates, and a change in these times and changeover dates by the politicians will automatically change the times of certain events which have been scheduled within that time zone.
Example: An event was scheduled on October 2, 1997 at 14:00 in Norway. Then the Norwegian parliament changed the time zone offset for that date from +01:00 to +02:00. Political decisions can even split time zone areas, it is conceivable that England and Scotland might select different time zone offsets at some time in the future. If the event was originally specified as {14:00; Norwegian time; Norwegian time zone definition}, then the item "Norwegian time zone definition" must be republicized, and all times scheduled with that time zone must then be shifted.
Certain events (example flight schedules) may start in one time zone and end in another time zone. Since the flying time does not change, a change of one of the time zones but not the other will cause a change in the arrival time.
After that I had to leave to prepare documents for the MHTML meeting, so I cannot report on what was more discussed in this meeting.
This group is also at the end of revising the last problems in the HTTP/1.1 specification.
Proxy-redirect (response code 305) is vague, maybe broken. Will have to be redone.
Content-Encoding is client to client, while Transfer-Encoding is encoding of individual hops. By "encoding" HTTP people mean "compression". Performance tests show that Content-Encoding can give much better performance than Transfer-Encoding. Content-Encoding can go through proxies, which Transfer-Encoding cannot. This is both an advantage and a disadvantage with Content-Encoding. If a proxy stores an encoded document, and then delivers it to a client which cannot handle Content-Encoding, there will be garbage on the screen.
Sessions which I did not go to, which are related to HTTP:
The MHTML standards has now been a proposed standard for almost a year, and a revised proposed standard will soon be submitted. The work is in the final stages of getting the new proposed standard ready. Issues discussed at this meeting were:
Status of implementations: We are ready to begin asking implementors to supply information about which features they have implemented, using a questionnaire I have prepared and which is available on the net.
Many implementors have chosen to just ignore information they cannot handle in HTML-formatted messages, not even telling users that information has been suppressed. I am not very happy with this, but since this is a rather common way of handling HTML, the group did not see any possibility to restrict it in the standard. One can only hope for more responsible implementors.
Another issue is whether to allow multiple Content-Location in one Content-Heading. Alex Hopmann argued rather well for allowing this. He said that the same web document often is referred-to using different URLs. If multiple Content-Location is not allowed, one might have to send the same document more than once in different body parts. The group accepted his position. The problem is that Content-Location is used to derive base, and if there are more than one, which of them should be used. Alex suggested, and we decided, that if you have multiple Content-Location, then none of them can be used to establish a base. If a base is needed, it has to be established by other means in this case, such as by inserting a (single) Content-Base statement in the heading.
We discussed the usefulness of adding a third alternative to the "Save" command in Web browsers. Today, the alternatives are usually "text" and "source", and a third alternative might be MIME. This would be different from source in that also all inline objects like graphics and applets are saved, so that the whole document is saved in the file, not only the HTML part of it. Implementors will probably develop this, but we did not feel much need to mention it in the standard, since it does not influence the protocol over the line.
Everyone agreed that a change in the original of any of the body parts sends in a MIME message should not cause a change in the message as shown to its reader. Only changes in parts not sent, but only referred to (through message/external-body or URLs not resolved by otherbody parts) can cause a message to change after transmission.
We did decide to say that our standard does not cover the combination of multipart/related with message/external-body.
We discussed nesting of multipart/related within multipart/related. Alex argued that an inner multipart/related should be allowed to contain URLs referring to body parts in outer multipart/related. We decided in acdordance with Alex's suggestion.
I presented some ideas for making multipart/alternative more readable, but the ideas were not very popular. I will submit them in writing to the list, hoping that careful reading of the texts may cause people to like my ideas more.
We decided to have a small editing meeting later during the week (just me, Alex Hopmann and Nick Shelness), then to submit a new draft, and aim at starting working group last call on the 5th of January and then, two weeks later, forward the new proposed standard to IESG. After that, Einar Stefferud said that the working group might go into hibernating status.
More info at URL: http://dsv.su.se/jpalme/ietf/mhtml.html.
EDI = Business transactions like invoices, loan requests, money transfers, etc. The health care industry is also interested. They want to transmit diagnosis, prescription information, medical information between medical doctors. Germany is especially interested in this. They have special legal issues of protection of health care date. Laws in many countries strictly controls who may access medical records.
Security is important in this work. The standards support use of either PGP or S/MIME, but all implementors have chosen to implement only S/MIME. To avoid messing up of digital seals by gateways (for example by converting between quoted-printable and base64) messages are sent encrypted. The escrow problem (where governments in various countries require deposit of keys to allow law enforcement agencies to break encryption) has caused people to use double encryption, so that not one single law enforcement agency can break digital seals and signatures.
EDI was first sent through SMTP, but also EDI over HTTP is being developed. EDI through SMTP has already been implemented by 9 companies. HTTP does not have the Content-Transfer-Encoding problems of SMTP. The POST command of HTTP is used for sending EDI.
EDI may be sent with a first body part in human-readable format and a second body part in an EDI-specific format.
EDIINT is discussing whether to use multipart/mixed, multipart/related, multipart/EDI-response or a modified version of multipart/report. Keith Moore said that Message Disposition Notifications were never intended for this, and is not suitable.
Wow, this was a popular subject. The room was overfilled with people. All seats occupied, lots of people standing in the aisles. The organizers said that no discussion of any political or legislative solutions to spamming would be allowed, only discussion of technical solutions. We had only one hour, so only selected people were allowed to speak, based on pre-submitted overheads. John Klensin was chairman.
Gunnar Lindberg, Chalmers university, Gothenburg, author of draft-lindberg-anti-spam-mta-00.txt, proposed restriction to the free relaying of e-mail. An MTA should not accept to relay any number of messages from any bogus sender. An MTA may also refuse to accept mail from certain hosts. Before accepting mail, MTAs should verify the MAIL FROM address, the RCPT TO address, the SMTP Caller ID. Only RCPT TO for your own local recipients should be accepted.
Phil Servita, Epilogue Technology: proposed that e-mail addresses should have two parts, a constant part and a time-limited part. The time-limited part is changed regularly.
Paul Hoffman, IMC:
Filtering: Heuristic filters, cooperative filters.
Heuristic filters are of two categories: filtering on originator and on looking at the message.
Origin filtering: Refuse IP connection for certain IP addresses, refuse TCP connection, refuse SMTP message from certain MAIL FROM senders, refuse SMTP messages.
Message filtering: In MTA or in the MUA.
Accountability: Authentication of sender or of first hop.
http://www.iomc.org/ube-sol.html.
Someone: SMTP Authenticication. Would allow servers to restrict mail relay service to authorized customers. Anti-third-party relay can then be applied using stronger authenticication than IP address.
Someone: Not a long-term solution. Internet better network bureau. Mail abuse protection service maps. People want to put on the stop lists not only spammers but also hackers, in his experience.
Someone: SUBMIT protocol. Authorized users use submit port with authenticication. Requires that submit is authenticated and that users can submit without being in the local network.
Someone: Spammers exchange names of open relayers with each other. They use toolkits. We must also use toolkits to fight them.
Someone: We may not all agree on what is a spam. One person's spam may be another persons newsletter.
Someone: www.sendmail.org has toolkits for anti-spamming. But it only works for sendmail.
Someone: Problem with authenticating MAIL FROM: Empty MAIL FROM is part of accepted protocols to stop loops.
Someone: I want to be able to provide relaying as a service. Not nice to have to tell people that you will not provide this service any more.
Someone: Spammers will learn to circumvent the measures we develop.
Harald T Alvestrand: Mailing lists can do something more.
Keith Moore: Responsible companies may not be a problem, they will regulate themselves.
Someone: In some countries, filtering of message body may be in violation of privacy protection laws. Only filtering in client would be allowed.
Someone: Do not stop them, slow them down. That way they cannot as easily move to some other relayer.
Carl-Uno Manros: Not only e-mail, also other protocols, for example Internet Printing Protocol, might be vulnerable to spamming.
Someone: Establish black lists of spamming identification, to exchange between anti-spammers. Someone else countered: You can expect to be sued.
My opinion (I never got the time to speak at the meeting): All these ideas of making it more difficult for spammers will not have very much effect. They may stop spammers from misappropriating other MTAs, but they will not stop spamming, spammers will just adjust to the new rules and send messages which cannot be detected as spams. I think that spam-control needs some kind of very fast data bases for distributing information about which messages are spams. It might be useful to use the PICS standard, since that standard allows that messages which are spams to some people are desirable to other people.
From the charter for this working group: This working group exists for the purpose of creating two documents: The first document, a BCP RFC, will be the process for registering new URL schemes. The second document, an Informational RFC, will be a guideline for the creators of new URL schemes. The purpose of this guideline will be to help ensure that new URL schemes:
The following issues are considered beyond the scope of this working group and shall not be addressed by it:
This group has problem with low activity, few comments.
Lots of people may want to register their own URL schemes for their own private data structures. Microsoft suggests using "DNS" concatenated with your DNS-name in order to get you a unique URL scheme name.
Read draft-iesg-iana-considerations-01.txt to learn how to write IANA considerations in an IETF standards document. There should be a "no registration needed" policy for these kinds of URL schemes.
Some people want short, descriptive names, which requires registration policy. Other people prefer a DNS-like system where you can get a globally unique URL without registration. Perhaps three spaces are needed: Short-registered-name-space, standards-track-space, DNS-type space.
For short, nice names, there might be a trademark conflict. Suppose someone wanted to register the URL scheme named "navigator"?
For MIME types, the "vnd." name space is used for vendor-specific MIME types. The same principle could be for vendor-specific URL schemes.
This was a very popular group, the room was overfilled, more than a hundred people! This is not only because IETF meetings in general get bigger and bigger, because other meetings had much smaller attendance. This group worked quite well in spite of the size, because most people were listeners only, not active participants. (In the anti-spam meeting, the number of participants did cause problems in getting results, but that meeting was also limited to only one hour.)
LDAP is a variant of X.500 which is getting wide acceptance as the directory system standard to use in the Internet. LDAP, like most other directory system standards, has the problem that they only work globally if there is an established system of co-working directory servers. This is a much more difficult goal to achieve then deciding on a standard, and that was the major issue for this meeting.
Mailing list: ietf-lsd@listserv.umu.se, to subscribe write to listserv@listserv.umu.se with "subscribe ietf-lsd" in the body of the message.
Archive: ftp://ftp.umu.se/ietf-lsd/
There is a need for a tool to locate LDAP servers. Since X.500 can be used with many different schemas, a way of mapping schemas is needed.
There is a need for guidelines for how to write schemas and schema mappings. There is a need for a document about naming and interconnection.
This group will in the future belong to the operational area, not to the applications area of IETF work. But at this meeting, the group was announced as belonging to the applications area.
Two naming schemes: The traditional geographical scheme and the DC naming scheme.
Directory systems are used for three different kinds of uses:
This is a cause of some problems in defining the standards.
Schema has two parts:
There are some problems in agreeing which schemas should be standardized by IETF and which can be left to different implementors to specify the way they prefer.
The schema mappings document may be removed, since most people who had an opinion on it should it should be removed. Most people voted neither yes nor no, which indicated that most people present were not experts on LDAP and X.500. The concept may be kept even if the specific document is removed.
About 40 people present, less than some earlier drums meetings. Perhaps it was the late hour, perhaps because the most important issues have already been resolved.
This meeting was held late in the evening (19:30-22:00) and this may be the reason why people said many funny things and laughed many times. For example, in a discussion about SMTP response codes, someone suggested "666" for "destroy everything" which got a very hearty laugh from the audience.
Like most IETF meetings, a lot of the discussion was on technical details, but sometimes you can note important principles behind the details. One case of this was a number of proposed syntax simplifications in the generate grammar for e-mail, to make it more similar to the grammar used in Usenet News. Making e-mail and Usenet News more compatible is important for the future, since messages will move more and more often between the services or be submitted at the same time to both. Note: This is the generate grammar, the grammar which conforming mail systems should generate. The accept grammar should of course accept all the old formats which old mail systems will continue to produce because they have not adapted to the new standards.
(The fact that the new e-mail standard has two separate standards for accept and generate is a great step forwards. It helps implementors by putting meat into the golden rule of the IETF, "Be conservative in what you produce, liberal in what you accept", and meat in this rule makes it much easier to implement, and thus favors interworking between different software products.)
Is it legal to have more than one To, Cc or Bcc header field in a message heading. RFC 822 says that it is allowed, but that the meaning is undefined. The opinions were divided, but I believe the decision was not to allow it in the generate grammar (but of course accept it in the accept grammar).
Again some syntax discussion.
The important issue: When will different messages have different Message-ID. This is important because some systems use Message-ID for loop control, duplicate control and to keep threads together. On the other hand, one should not assume that two messages with the same Message-ID are identical, because for various reasons messages. The conclusion is that the text should explain the issues in more detail than today, but not say exactly that Message-ID MUST change in certain cases.
There was a lot of discussion of details in SMTP. I only note some "highlights". Should servers be required to accept EHLO (even if they only handle it as HELO). Most people seemed to want this. Should NUL characters be allowed in messages sent through SMTP (even though they are not allowed in RFC822, I believe). This is very controversial.
For several years now, the issue of what to do with the "Reply-To" e-mail header has been very intensive in the drums mailing list. An enormous amount of messages were written on this issue in the time period July to November 1997.
The issue is the following: When an e-mail user sends replies, different kinds of replies to a message should be sent to different destinations. Some replies are suitable to send only to the author of a previous message, or to some specific person who the author has designated to handle replies to this particular message. Other replies are suitable to send to all recipients of the previous message. This is often the case for discussion messages in an onoging discussion, often through one or more mailing lists. But also in this case, the reply should sometimes not be sent to every recipient in the list of recipients on the replied-to message. For example, Bcc recipients usually do not get replies, and if a person is a member of a mailing list, s/he may prefer to get replies only through the list and not to his/her personal e-mail address. Finally, there are cases where an initial message starting a thread is cross-posted to several mailing lists, but where the author suggests that future discussion on this issue should only go to one of the lists.
The "Reply-To" header is a way for tha author of a message to indicate where replies to his/her message should be sent. But the author might wish different kinds of replies sent to different sets of recipients (see above). Another related problem is that some mailing list expanders add a "Reply-To" header, referring to the list, to messages passing through the mailing list expansion process.
The solutions which have been discussed are to phase out "Reply-To", or to keep it but restrict its meaning (RFC822 is ambiguous in what its meaning should be). Three new possible e-mail headers have also been proposed, "Personal-Reply-To" (for replies to a single person, often the author), "Mail-Followup-To" (for replies to all or most of the recipients) and "Reply-To-Meaning" (which would be used combined with "Reply-To" to explain what kind of replies it is meant for.
Keith Moore has made a very complete list of 15 issues in this discussion, in spite of this some people (including me) feel that some issues are left out of his list. Here is a short summary of some of the most important issues:
Chris Newman tried to arrange the discussion in an orderly manner by going back to basics, beginning with user needs. He asked how important we fould the following different user needs to be. The numbers below are averages on a scale from 1 to 10.
We did not get very much further, and definitely did not get to any results. Only about an hour was available for discussing this issue, which was much too little. At the end, Chris Newman threatened "If you cannot agree, we will have to go back to the RFC822 definition of Reply-To again". I said that there were several different possible solutions, and that our decision procedures must be such that they allow consensus if we find a solution which a large majority finds good, even if some members find another solution slightly better.
The Internet fax meeting was interesting in that a lot of the time was about administrative issues in co-ordinating IETF and ITU work on standardizing fax through e-mail. Apparently, two variants of this is (1) To publish separate documents, which are hopefully identical (2) One organization publishes a document which references the document from the other organization. Choice (1) has the disadvantage that there may be discrepancies between the documents.
The ITU co-ordinating strongly influences the time-table of IETF work, to fit the more rigid timetables used by ITU.
There was some discussion about conformance to Internet e-mail standards. They plan to reference the existing MIME conformance document (RFC 2049) and list the exceptions. Some exceptions from Internet e-mail standards to be included in the Internet fax standards: