Notes from the IETF meeting in Memphis, April 1997

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. Last revision: 25 April 1997.

Table of contents

Terminology
HTTP Development Meeting
Sending HTML in MIME - MHTML
Drums - e-mail standards revision
Responsible Use of the Network
Uniform Resource Locator Registration Procedure BOF
Listheaders BOF
Process for Organisation of Internet Standard
Pricing
Further references

Acknowledgements

Grateful thanks to the commission of the European Union and the Fourth Programme Telematics Area Scimitar project for contributing to the cost for my travel to this meeting.

Introduction

These are personal notes, no official minutes. I have just noted down phrases I heard or saw, so a statement quoted below may not be either my personal opinion or the group decision. Because the EU is paying for my travel to this meeting, I am using English and not American spelling in these notes.

Terminology

Rat hole
An area where there is much controversy, and which should because of this be avoided in standards (I do not agree with this, that one should avoid standardising controversial areas, but this is the accepted belief among IETF people.)
Broken
Standard or part of a standard which cannot work because of technical problems or disagreement between different parts of the standard.
F2F
Face-to-face.
Area director
Very powerful people controlling all standards work in a particular area.
Slot
Period of 1-3 hours allocated to a working group for F2F meeting during an IETF meeting. Slots are difficult to come by, there is competition to get one, the area directors decide who gets a slot. At this meeting, a number of shorter one-hour slots were allocated, in order to allow for more slots within the limits of the meeting and location.
BOF
Birds Of a Feather, meetings of people who have not yet become an IETF working group, to discuss the establishment of a new such group.
Munge
Modify some protocol information you are not supposed to modify, for example changing the date header in an e-mail message you are relaying.


HTTP Development Meeting

Information about current issues (in moving HTTP/1.1 from proposed to draft standard) can be found at URL:

http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/

About 40 people were present. The chairman sometimes asked, for particular issues "How many people present understand this issue" and usually only 5-10 people put up their hands. This is common in IETF, that many people present have not learnt the issues in advance. This is no problem, as long as these people stay silent and do not obstruct the meeting.

Like normal in IETF, there was a lot of discussion about minor technical details in the protocols. These might be very important to implementors, and clarification of such things is a major goal of IETF work, so do not interpret me as saying that these details are unimportant.

"Are quote characters allowed inside quoted strings?" "HTTP/1.0 is broken, but we have to stay with it."

The meeting was split into two slots. In the first slot, several times some person said that he did not know how his browser handled a special case. The chairman then asked this person to find out and report during the second slot, which I did not have time to vist.

Sending HTML in MIME - MHTML

There was no official meeting for the IETF MHTML working group (in which I was editor of the main document) but an informal meeting was arranged over lunch one day. Present were implementors from several major manufacturers of e-mail software. Especially impressive was the Microsoft presence, of the eight people coming to this informal meeting, three or four seemed to come from Microsoft!

We began the lunch by a toast to celebrate that our standard is now published as an IETF proposed standard (the first stage in the proves to become an IETF standard, the second stage is draft standard, the third stage is full standard and the fourth stage (for some standards) is historic (obsolete). All were serious about implementing MHTML, so we can expect soon to be able to send e-mail messages in HTML format. This means, for example, that you will be able to send questionnaires via e-mail as HTML forms, and have the replies sent back via e-mail. You will also be able to utilise all the formatting facilities of HTML including in-line graphics, Javascript and Java, in e-mail messages. I believe this is going to revolutionise the way e-mail is used.

Those e-mail vendors which are not also vendors of web browsers (for example Eudora) will use the web browser of the user's choice to display HTML messages. This requires that the web browser manufacturers will allow their web browsers to be used as helpers to e-mail software. I understood that this does not always work the way it should, but also everyone at the meeting seemed willing to do what is needed to get this working. Someone said that at present this works for the Windows but not the Macintosh version of Microsoft Internet Explorer. There is also a need for a web browser owner to be able to configure his web browser to use the e-mail client of the user's choice to handle mailto: URLs, all versions of the major web browsers do not yet support this.

Here is a list of some implementation problems mentioned at the meeting:

Quoting passages from replied-to messages
A problem with HTML-formatted messages is that the conventional way of copying part of the message you are replying to into the new message, by adding "> " in front of copied lines. This does not work well with HTML. Some of the participants said that they were working on a proposal for a special variant of the HTML BLOCKQUOTE or CITE elements to mark such sections in a message, with a special attribute to specify that this is a quote from an e-mail message. Web browsers might use special markup for such sections, such as a solid vertical line to the right of such quoted passages.
Resolving URLs
Some implementations may need to resolve relative URLs based on Content-Base statements, and this is not exactly easy. This is mainly a problem for those who are responsible for mail systems separate from web browsers, for those who are developing mail systems integrated in web browsers, the software in the web browser for such resolution can be used.
Signed messages
Electronic seals depend on an encrypted hash code of the message, and this requires the message to be unchanged, otherwise the hash code will change. This means that if you unpack a multi-part message, you must also keep the original message in non-unpacked format to be able to check the electronic seal on them. Someone said that this is a general problem with secure e-mail, not particular for us, and that IMAP users may have special problems, since IMAP allows the downloading of parts of a message. IMAP does also permit the download of the whole message, but if you have to do this to check seals, you may have to download a message twice, which is obviously time-consuming.

In the IETF meeting in Munich in August, we plan to hold a formal meeting of the MHTML group to check implementation progress, look at the informational document with advice on how to use the MHTML standard (which is still an IETF draft) and maybe start work on progressing MHTML from proposed to draft standard.

Other interesting things I heard was that e-mail will definitely move in the direction I have wanted (and KOM implemented already twenty years ago): Into a data base view of e-mail, where users will be able to scan threads, find the replied-to and replying message, search for message by A to B after date C with keyword E, etc.

More info about sending HTML in e-mail.

Drums - e-mail standards revision

This group is responsible for revision of the basic e-mail standards, RFC821 and RFC822. The group may not add new functionality, just clarify how this should be done according to existing standards.

RFC822 revision

Latest draft: draft-ietf-drums-msg-fmt-01.txt. (this document will not be available with this URL until later in April 1997, but it was available for discussion during the meeting.)

Where should replies be sent? Default Reply-To, if no Reply-To, From, but writer of reply can always change the recipients of the reply to anyone/anything else.

Line length will be recommended to be 78 characters plus CRLF (Longer lines can be encoded using Quoted-Printable or Base64) in headers and body of e-mail.

Should some obscure syntax be allowed, like "foo".bar@host.domain?

Many seldom-used constructs in e-mail are stated as obsolete: All implementations SHOULD accept it in input, but MUST not generate it. Examples:

The above means that the new RFC822 replacement will have two syntaxes and two grammars. One more restricted send-syntax and send-grammar, and one more liberal accept-syntax and accept-grammar, where certain obsolete elements are accepted. I like this very much, it is an acceptance by IETF that the standards ideal and the real usage may not always agree. I have unsuccessfully argued similar things for many years.

There has been a lot of discussion about the RFC822 requirement that dots in local parts must be quoted, so that 'John F. Kennedy <johnf@cemetery.arlington>' must be written '"John F. Kennedy" <johnf@cemetery.arlington>'. This is probably the mostly-broken rule in RFC822, and has had eternal discussions in the IETF group, but the requirement will not be removed. There are too many existing mail systems which have problems with this.

There was some discussion about different ways of forwarding messages. Resent should not be misused, and the right way to do forwarding is to use MIME, with encapsulation of the forwarded message as a body part. Someone SHOULD write an RFC on how this is to be done, it will be popular with the IETF mail community, even though very few existing mail systems support this today.

Some people wanted to disallow "Resent-" entirely, other liked it, in particular I said that I wanted to use it for sending my own messages to additional recipients after the first transmission of the message, and Pete Resnick wanted to allow it in order to show the recipient how the message got into his mailbox.

Year 2000 issues in e-mail standards

The only year 2000 issue which was known to the group in e-mail was the date format in RFC822 which specifies two-digit years. This was corrected in RFC1123 already in October 1989. The problem is that there are still implementations which do not seem to have seen RFC1123 and which still use only two-digit years.

RFC821 revision

Latest draft: draft-ietf-drums-smtpupd-04.txt.

Relays should not mess with message bodies and headers, even if they are illegal. Either accept them or bounce them, but not modify them. Especially, sending unlabelled 8-bit stuff should not cause the relay to correct the format by 8-bit labelling or conversion to 7-bit format.

Note: A relay and a gateway is two different things. Gateways may have to modify messages, even if relays are not allowed to do it. A third case is submission, some systems are defined so that the first MTA which gets a message does certain corrections to it. This third case may become a new standard, it is not part of the current work. I tried to argue for a fourth case, mailing list expansion, and that we should state that the present standard does not cover that case either. But the editor (John Klensin) did not like that, the issue of what mailing list expanders may and may not do is such a controversial rat hole that he prefers not to mention it at all. Any mention of it may be interpreted as a statement on how this controversial case is to be handled.

ABNF

Latest draft: draft-ietf-drums-abnf-02.txt.

ABNF is the syntax specification method used in e-mail and many other Internet standard. It can be seen as the ASN.1 of the Internet. Dave Crocker is now writing a separate RFC about ABNF (previously it was defined as part of RFC822). There has been some discussion about some new additions to ABNF. A new construct under discussion is %d10..12 to specify characters with decimal values from 10 to 12. Another construct is %d10.12.15 to specify one of the three characters with decimal value 10, 12 and 15. Can they be combined? Or does it mean the three characters with decimal value 10, 12 and 15 in succession? Some discussion, no agreement. Probably none of these constructs will be allowed, because people during the meeting pointed out problems with all of them.

I did not quite understand this, so I will just write down what people said. Problematic examples were said to be: "%xab..c". Is "%x41..%x5a" better than "'A'..'Z'". We discussed for 20 minutes whether a dash or two or more dots was best for some notation, I did not try to understand what the issue was and why this was so important. John Klensin said that extending ABNF with many new constructs, in order to create a very concise specification language, is like moving from Fortran to APL. (Most people know that APL is a language with so compact and powerful notation that its programs are virtually "write-only").

I said that my experience as editor of the MHTML standard was that the most difficult part of writing this standard was to get the examples syntactically right and that a parser which takes ABNF as input and then syntax-checks examples would have been very helpful to me. Other people said that ABNF is mainly a specification language, and that whether it can be used to run automatic parsers is of secondary importance.

Another new construct called "sets" has been added. A set is an unordered set, not like a sequence where the elements must go in a certain order. This has caused some discussion on the mailing list. This is needed because there is no good way, today, in ABNF to specify that some header fields in an e-mail header can come in arbitrary order.

   {foo bar}
would for example be a short form for
   (foo bar)/(bar foo)
but also more than two elements in the set would be allowed. This construct has problems in defining the meaning of constructs like
   {#foo bar}
people claimed. The problem is whether you should first expand
   #foo
and then say that the expanded elements could come in any order, or should
   {foo bar}
be interpreted as
   {(foo) (bar)}
i.e. first sort in arbitrary order, then expand.

The advantage with allowing
   {*foo bar}
to expand before sorting, is that this would be useful to specify that a mail header can contain for example more than one "To:" header, occuring in arbritrary order among other fields in the header. The disadvantage is that there are difficult implementation issues in defining sets fully if we expand before we sort.

The alternate notation not using sets might be

   header = *header-field
   header-field = to / from / sender / cc / bcc / ...

which allows more than we really want to allow (it allows all headers to occur multiple time, while in reality some headers may only occur once in an RFC822 heading).

The final conclusion was that the new set construct will not be added to ABNF. Instead, the notation above would be used, combined with a table which specifies the information which the above notation cannot capture.

The #-notation of ABNF was also discussed a long time, because it is not well defined (some people interpret it to allow different kinds of whitespace around the ","-s). The final decision was to remove this from ABNF, and let anyone who needs this define it using more basic syntactic constructs.

The #-notation says that
   #foo
means
   foo / (foo, #foo)
and that
   n,m#foo
controls how many elements are allowed in the list.

My personal comment: It is interesting that an issue like these, which do not in any way have any influence on user functionality, and thus should not be very important, tend to be discussed very much in standards groups. Two and a half hour was spent on these issues, instead of discussing issues which really causes problems for users of e-mail, like for example the ambiguity of the "Reply-To:" header.

There is also some work in standards groups for data-base-oriented information exchange, like calendars, to define a new data description language for Internet usage, maybe a new ASN.1? This work was not mentioned in the drums working group.

Responsible Use of the Network (RUN working group)

Mailing list: ietf-run@mailbag.intel.com

to subscribe mail listserv@mailbag.Intel.com with the text "subscribe ietf-run".

Archives: ftp://ftp.intel.com/pub/ietf-run.

There is a general draft on responsible use of the Internet, but there is a need for one or more new documents on responsible advertising on the net.

The chairman thought that the word "spam" could not be used because it is a trademark of a meat product. Other people said that this is no problem, since e-mail advertising is a different area than meat products. But other people said that negative connotations of a trade-mark is forbidden also in other areas. A alternative word "spew" was not liked by the group.

There is an Internet draft "draft-ietf-run-spew-00.txt" which we discussed.

I suggested that the document must contain a definition of what is accepted and not accepted. For example, is it permitted to send advertising to people who have voluntarily subscribed to mailing lists for sending out commercial information (yes). Is it permitted to require people to provide their e-mail addresses in order to buy products or get free samples (maybe)? To what extent can an e-mail address given by a person for use to send news about a certain product be used to send information about other products?

There was some discussion on which actions against spamming are acceptable. Should one CC the local postmaster or not? This may be causing more problems, not helping anyone. Some organisations have special "abuse@domains" to which you can send complaints about abuse.

There was discussion that the federal government in the U.S. could prosecute spammers for misusing their computing resources. Companies with many e-mail users could also do the same.

Mailing list allow "unsub". You should not sell mailing lists. Clarify how a list is to be used before soliciting members to the list. All advertising messages must clearly indicate who is responsible for them. Do not munge e-mail headers.

Telling people how to unsubscribe from the list is not enough to make spamming acceptable, especially since spammers often use one-time mailing lists, so that your unsubscribe messages do not gain you anything.

Advice people about alternative, legal means of advertising on the net and in other places.

Blinking banner advertisements could be avoided by plug-ins to your web browser which stops such banners (disable blinking in Netscape, disable moving java applets, etc.)

Security considerations

Certain actions to stop spamming may cause problems to legitimate users of the net. There is a risk that filters to stop spamming will unintentionally stop legitimate mail too. Overloading postmasters with complaints about spamming may cause trouble to the wrong person, someone who is not responsible for and cannot do anything to avoid the spamming activity, or it may cause trouble out of proportion to the abuse you are complaining about.

Uniform Resource Locator Registration Procedure BOF

Name:
URL Process & guidelines BOF (URLREG)
Mailing list:
ietf-url@imc.org
To subscribe:
Send message ietf-url-request@imc.org with the body of the message containing the single word "subscribe".
Web page:
http://www.imc.org/ietf-url/
Current I-D:
draft-masinter-url-process-01.txt.

The task of this group is to define a procedure for registering new URL types (schemes), not for registering URLs. New URL schemes may cause a lot of effort for example for browser developers, so they should not be accepted without reason. They must provide needed new functionality which is not provided by existing URL schemes, and they must agree to accepted rules for syntax of URLs, for resolution of relative URLs (if such are to be allowed), etc.

Issues: Do all new URL schemes require standards track documents, or can they be defined by informational documents? There are many local schemes in special environments.

Is there a real need for a registration scheme? Someone said that registration would enable browsers to provide better error messages when people mistakenly use URLs not legal in their environment, for example the AOL URL outside of America Online. Should we have two track, one lower track for less important new URLs and one IETF standards track for more important new URL schemes. Would it be a problem if too many private URL schemes cluttered up the IETF registration procedure.

There was some discussion about whether IANA can revoke already registered entities. Harald said this is possible, if we define the rules for revoking registered entities.

New URL should not be trademarks, and should be reviewed by a significant portion of the users of the protocol which is to get an URL.

Internationalisation: National character sets in URL scheme names are probably not needed. But someone said they had already seen URL schemes using Kanji characters.

URNs will define their own registration scheme, so the work of this group does not apply to the registration of URNs.

Listheaders BOF

draft-baer-listspec-00.txt
draft-hoffman-mailto-url-01.txt

LIST-SUBSCRIBE:
<mailto:list-header@arpp.carleton.ca?subject=subscribe>
LIST-UNSUBSCRIBE:
<mailto:list-header@arpp.carleton.ca?subject=unsubscribe>
LIST-HELP:
<http://arpp.carleton.ca/listspec/> (this web site also contains a lot of other information)

These are new rfc822 headings to tell you how to subscribe and get information about a mailing list. Several mailers already support these with commands to unsubscribe based on this information. You can also, of course, put them in any web page or message text, in order to inform people about how to subscribe and unsubscribe from mailing lists.

There was some concern, but not very much.

There are advantages and disadvantages in putting this in the RFC822 headers. The disadvantage with putting it in headers is that those are not always protected by digital seals. But nothing stops you from putting this information also in other places, for example web pages or message texts or content-headers.

There was discussion on whether a new IETF working group is needed or not. A working-group takes time to set up, needs a charter and milestones, tends to include new tasks, tends to take time. Because of this, most people seemed to feel that it should not get into a working group. A working group might later on be started to handle further mailing list issues. However, IETF has earlier bad experience with getting agreement on fuller standards for mailing lists.

I suggested there should be a way to indicate alternate ways to perform an action, for example help via either HTTP or MAILTO. The answer was that in that case you can include multiple LIST-HELP headers.

Process for Organisation of Internet Standard

NomCom = Nominations Committee

The NomCom committee has the task of nominating proposals for replacements of open positions.

The goal is to replace 50 % of the members every time. There is some problem in getting alignment to this division, since it is now uneven. When there are two area directors in one area, they want to replace one and keep one each term. But what happens if one of them does not want to continue any more, and the other is performing badly, should he in spite of this be kept for a second or third term?

A long complex discussion about how to avoid a poor person causing an area to languish for two or three years.

"How can we enlarge the pool of volunteers?" "Should this list be published?" "Should it contain stars in front of those who are qualified?" "Should it be published incrementally, or only once at start of the selection procedure?" "Do incrementally?"

"Must everything be in the charter, or is it dangerous to put too much into the charter, when we have to do it a different way?" "Will the chairman of the Nominations Committee be willing to perform any action which is not supported by the charter?" "Do you show much experience in IETF work by coming to F2F IETF meetings, or by being active in mailing lists?" "Is it, or is it not, a requirement that anyone going into the IESG must have previously shared an IETF working group?" "No, we should not disqualify a good person by this kind of formal rule."

"The ability to encourage people to misunderstand the status of standards is clearly utilised!"

Standards Writing and Publishing Procedure

Difficulty to reach agreement. Last year, a decision was taken that a list of all standards should be published in every RFC with numbers ending in 00. But this procedure has not been followed.

"The process of standardisation is cheapened by developing too many standards with too little value!", said someone.

"Every single option of every standard must be implemented by at least two interworking implementations", someone said. "But all standards developers do not know this!" "Everyone doing testing everything together, putting all systems in a room and running them against each other for a week, should happen more often."

"Planned interoperability tests." "Is this our work, no, we are not a testing organisation." "Should a full standard be accepted only if a report from an interoperability test is produced?" "This depends on what kind of standard. A low-level protocol which can cause race conditions has to be tested for every state combination of the interoperating implementations, but this may not be necessary for all features of an applications layer standard".

"Should we stop publishing RFC-s, because of the many misunderstanding of what an RFC is?" "Will new, other terms be less abused?" "Can anyone publish any kind of trash as an RFC?" "Should we cluster together a set of documents, when some of them are draft standards, other are only informational?"

Can IETF Standardise Pricing Policies?

Standards may cater for the collection of statistics as a basis for pricing, for the transport of accounting data, but not for defining specific pricing policies.

IANA resource allocation documents are not standards.

IAB can form policy sub-committees.

Documents about the effects and consequences of various pricing strategies can be published.

Further references

  • Internet Engineering Task Force (IETF)
  • IETF applications area
  • IETF work of special interest to me