These are my personal notes from some of the application layer sessions, not any official minutes.
Table of contents
Calendaring and scheduling
The Westin Bonadventure hotel
was really impressive. Five 30-floor towers, four in the corners, one in the middle,
connected by narrow corridors with 12 scenic elevators. The bottom six floors was
a shopping arcade with 20 shops and 19 restaurants, large like a medium size shopping
center, all with entrances opening to a large central indoor hall. At the bottom
of the hall, indoor water fountains with arches of water spraying around the walkways.
The object of this working group is to produce a standard for sending calendar data (meeting times, requests for bookings, time schedules) across the network.
An issue of this document was security. Security depends on not-ready standards, like SMIME, so either the group must delay its standard, or publish it without security in the first version.
Can there be different, conflicting copies of the same calendar object in different agents. If so, is one of them the master original, and all the others shadow copies?
Do we support fully internationalized searching capabilities? May need language-specific searching methods! May need a new IETF working group?
Is there a need for a roll-back capability, if you have started several calendar operations on different calendar servers, and then want to retract some of them because other related calendaring operation failed.
Can a user ask the server to send out calls for a booked meeting, after having done the booking.
There was then a meta-discussion about must versus may requirements. The agreement seemed to be that at this stage, we should specify requirements on what should be supported by the protocol. Requirements on implementations is too early to specify at present.
Last time, the main controversy was about the problems of what happens with existing calendar objects when changing the date for switch over between winter and daylight savings time. If the decision of this switch over time is made after the scheduling of a calendar event, should that offset the calendar event by one hour, or should it not? And time zones came up on this meeting again. How can client and server agree on what they mean by time zones? Should a server have a default time zone, or should it not? Also clients may move from one time zone to another, so not even a client can be ensured to have a static time zone. Conclusions: No defaults, all time zones should be explicitly specified in all protocol elements.
Should minimal directory services be provided, or should such services be provided through a separate protocol like LDAP? "Find out if John is in London next week?" Should the calendar servers store information in LDAP-based data bases? If the calendar system can store groups (lists of users) should this be a service of the calendar system, or something done through LDAP? Example: A meeting is specified for a group of people. Should this group then be an LDAP-defined group, or a group defined in the calendar data base.
If you want to find out Mary's working hours, should you query a calendar server or an LDAP server?
SIEVE is a proposal for MTA-based filtering. Through the SIEVE protocol, an e-mail client can instruct a filter, running on a server, to perform filtering for the e-mail client. The filtering facilities are of the usual kind, a linear list of Boolean operations performed on incoming e-mail. The filtering facilities are intentionally basic, but there is an extension mechanism for extending the filtering and action choices. The intent is for this protocol to be executed on or around final delivery (not specified too exactly, to allow for implementation options, some user environment might for example want filtering to be done in a gateway to a limited mail system). An unresolved issue is how to manage extensions.
The present IETF draft only specifies the filtering language, not the protocol.
Published draft documents:
Author's goal is not to have an IETF working group started, but to have the draft submitted for last call as soon as possible. The proposal has been discussed for a long time in a mailing list, even though no formal IETF working group has been formed.
Harald T. Alvestrand said: Extension mechanism is very very useful. Should allow
users to specify procedures to be called for testing and action.
HTTP is becoming popular as a base protocol for different specialized application transfer protocols. There is then a need for a way to do capability negotiation to agree on which extensions to HTML the communicating agents support. Two proposals, PEP and OPTIONS, are being discussed. PEP is not active any more, but experience from PEP will be used in specifying the new extension mechanisms.
No one is able to track all the different extensions to HTTP, which people are doing in different places.
One goal is to collect experience of problems, which various protocol extension methods can create. Based on this, provide a document with dos and don'ts on how to specify HTTP extensions. This group will not standardize extensions, it will standardize extension methods.
Anyone who has done HTTP extensions should check if the extension mechanisms being discussed are suitable for their extensions.
One issue: Can you communicate things which are intended for proxies, and not end-to-end operations?
A separate working group may be started on HTTP Next Generation. Which group should
then be given the name HTTP-EXT? The group on extensibility mechanisms or the group
about future extensions? If this is going to be two different IETF working groups,
it is important to clarify the border, and to clarify that the present BOF is a group
for specifying an extensions mechanism, not to specify extensions.
Revision of e-mail standards (DRUMS)
Group name in recipient fields will be defined as a "display name" to show that it is for human consumption only and not globally unique, just like the part before "<" of ordinary names in e-mail headers. When exactly one mailbox is covered, group name should not be used, the normal part before "<" should be used instead.
IP-V6 addresses in domain names: The problem is that we do not know what textual representation for IP-V6 names, which some other group will specify, so we cannot specify the allowed characters yet.
Control characters in e-mail: Horizontal Tab (HT), Carriage-Return-Line Feed in sequence (CRLF) is allowed. Form Feed and Backspace are to be allowed, but recommended not to be used.
Line breaks in e-mail: The group strongly is of the opinion that line breaks in e-mail should be CRLF. There was some discussion of whether to allow bare CRs or bare LFs in the not-recommended obsolete accept language. The problem is that many mail handlers will convert bare CR or bare LF to CRLF, so these characters, if they occur singly, are liable to be changed to full CRLFs. Decision will be made on the list, but the group majority opinion seemed against bare CRs and bare LFs. At least, if you use them, you should know that they might get corrupted. They are not to be interpreted as line breaks. This is especially problematic for the last characters of a message. SMTP requires that the end of a message is indicated with CRLF-PERIOD-CRLF, and there is confusion on whether a message which does not end with CRLF should have CRLF added to the end to agree with the SMTP requirements. If a message ends with CR, is it then enough to add "LF.CRLF" to confirm to SMTP requirements?
Form Feed and Backspace characters in e-mail: They are not recommended, but can occur in text and unstructured header values.
Folding and unfolding of header lines should not add or remove spaces or tabs, it should only add and remove the line break character. Folding is only allowed before a white space character. I understood the meeting to decide that folding is to be allowed inside quoted header strings.
Header-registry: This issue was deferred, it may be turned over to a new working group, possibly combined with X-headers. This proposal was accepted at a previous IETF meeting, which decided to publish the registry proposal at the same time as the two main drums documents. This previous decision was thus overturned at this meeting.
X-headers: The intention with X-headers was that they could be used to experiment with new non-standard headers, without a risk that the new headers become standard. This has not worked. Some new bad headers, for example Return-Receipt-To, did not have X in front of them. And some X-headers, for example X-Priority, have become de-facto standard. There were two conflicting opinions in the group, one that X-headers, in spite of their problems, are better than nothing, one that they should be abolished. The idea was also proposed to replace X-headers with "<vendor-name>-headers", for example "Digital-DECNet-Address". This would require a registry of vendor-names, and only headers beginning with vendor-names in this registry would be allowed. Vendor-names which might conflict with existing or future header names, like "Content-" would not be allowed. I believe the decision of the group was that the msgfmt document remain silent on this, and that the issue is deferred to a new working group, possibly combined with registry.
Reply-To headers: This is at present problematic because Reply-To headers are used in two conflicting ways. One is as replacement for From, one is as replacement for all recipients when group replies are produced. We decided to explain the present ambiguity, and to describe Reply-To as a replacement for From as best current practice, and to defer definition of new headers like "Mail-Followup-To" to a new working group. This new working group might tackle other group communication issues as well.
This issue has been very controversial with tons of discussion messages, for several
years, and very difficulty to reach agreement. The decision at the meeting was to
record current practice (as a "From"-replacement) without saying that this
is the correct way to use this header. Current practice by mailing lists will, if
I understood the decision rightly, not be recorded, except possibly to recommend
Mailing list: email@example.com
What/who,why register content feature tags
Content feature tags represent individual and simple dimensions of capability or preference, like color depth of a display, support of a particular HTML extension, paper type available on a printer, TIFF profile understood by a receiver. The tags are one-dimensional, in one of the formats enumerated, discrete range or continuous. If you want to register a multi-value tag, you should register more than one tag, which can be done at the same time. Already registered features like MIME types need not be reregistered. Political, social or value judgments are not wanted.
Different branches in the registration tree can have differing registration requirements. IETF tree requires an RFC. Global tree requires submission of a registration form to IANA, URI tree requires no registration. The group will build a commonly used dictionary of terms useful in media feature registration.
IETF tree starts with ".", Global tree starts with "g.", URI tree starts with "u.".
Example of an URI tree entry: "u.http://www.sunshine.com/mytalks.txg (this also tells where you can get more information about this media type.
The tags may be transported in message heads, MDN bodies and HTTP heads.
When you register, you have to give the tag name, a short description, value pace, description of what the alternatives mean. This could also refer to an entry in the IANA MIME type registry, which applications will use it, examples of use, related standards, interoperability, privacy and security considerations, denial of service concerns. If there is an OID, you can indicate it in the registration. You can also specify keywords, related tags, related media types or data format, related HTML markup tags, who can give more information, who has change control.
Registrations can be posted to a mailing list for peer review, but this is not mandatory.
Examples of usage:
Issue: Metric versus imperial values, for example pixels/inch versus pixels/cm. Printers use inches, fax use centimeters, so both metric and imperial values must be allowed in some way.
This was a very controversial issue. Some people talked about all of the problems we will get into by allowing many different units, others said that pixels/inch will never be accepted by fax people and pixels/meter will never be accepted by printer people. I suggested pixels/254000 mm. Then if you have a value in pixels/inch, you multiply by 10000, if you have a value in pixels/meter, you multiply by 254.To get back the original values, just divide by 10000 resp. 254.
When you send e-mail to someone, they could return an MDN saying which media types they can handle, so that you can register this, and remember to send to them using the media types they are capable of handling.
Aggregation of features into feature collections.
Content negotiation requirements
Specifies a general framework and metadata for content negotiations.
A common vocabulary, a stable reference for commonly used features, an extensible framework, permit quality indication, capture dependencies between values, encompass existing features and extensible to future features, negotiations in both receiver- and sender-initiated transfers, structure independent of any message transfer protocol, recognize and address the use of content-negotiation in fulfilling needs of less capable computer users.
Discussion: Why is protocol independence wanted? Protocol dependence is because people want to understand each other better by specifying a protocol, what is wrong with that. Reply: By protocol-independence we mean that the same feature can be used, whether the data is transported through e-mail or HTTP or some other protocol.
Feature tags, capability/preference exchange, and negotiation
Content features algebra: Use LDAP filter string model specified in RFC 2254, it is good and useful.
This group develops a standard for sending e-mail in HTML format. The standard is in IESG last call, so there was no discussion of its content at this meeting. What we did was to discuss implementation status. Most implementors today support all the MHTML formats in input, but only produce HTML with Content-ID in output. The reason for this is that Netscape at present only supports HTML with Content-ID in input, and all implementors want to produce messages which can be read with Netscape. Netscape is, however, working on a fuller implementation of MHTML, and when that has been released, other e-mailers can be expected to start using Content-Location.
We discussed the questionnaire to be sent to implementors. I was asked to change the questionnaire to distinguish between what implementors provide with their own code, and what they provide with code from other vendors. The reason for this is that we want to find if there are two independent implementations of each protocol feature, and if vendor X uses vendor Y code, then vendor X is not an independent implementation from vendor Y.
We discussed the informational draft. We will try to get people in the working
group to check it, so that it can be forwarded. If possible, the standard should
contain a reference to the informational draft.
(There may be mistakes in the report below, since this is not my area of expertise.)
Mostly about scaling problems, especially for multicast. Problems are solvable in the short term, but there are long-term concerns, and a problem with lack of competent network operating personnel.
On multi-cast routing, there are several solutions, different solutions are best for different usage, there is scaling concern for some solutions.
On network address translation (NAT): Should the source address be the same if a TCP connection closes down and opens up again? Encrypted IP-addresses were not liked.
Type/quality of service: Hop by hop and set up of route service quality.
Routing security: Problem with bad packets.
Routing security: What can, and what cannot, be done with BGP. Tunnels and static routes can solve some problem s which BGP cannot solve. Some people complain that BGP is not symmetric, but other people said that no routing is symmetric.
Making network properties visible to applications: Early issue, not resolved.
Multi-stranded links: To get higher bandwith, sometimes more than one link is used between two routers. These could be treated as individual links or as multi-stranded links, the latter is preferred.
Management and diagnostic tools: A list of wanted better feature was prepared.
Automatic renumbering the net was discussed, no con conclusions.
Anycast addressing, an alternative to multicasting?
Executive director: Steve Coya
1997 activities: Meetings, major update of the data base, redesigned web site, automated onsite registration processing.
To make costs meet income without U.S. government funding:
With no U.S. government funding, IETF Secretariat is now a subsidiary of CNRI, and is a corporation.