IETF Meeting August 1998

Personal notes from some of the meetings,
mainly in the applications area,
during the IETF
(Internet Engineering Task Force) meeting in Chicago, August 1998.


By Professor Jacob Palme,
Stockholm University and KTH Technical University

What is written here is mostly quotes of what different speakers said during the meetings, it is not necessarily my own opinions on the issues discussed.


Table of contents


General Impressions


Many bofs

There was many BOFs in the applications area at this meeting. BOF (Birds Of a Feather) are meetings which do not yet have any assigned IETF working group. The reasos for the unusual amount of BOFs might be either:

  1. Unusually many new ideas, which have not yet been approved, or
  2. Meetings in areas where people have not established any IETF working group
    1. because of problems fulfilling IETF requirements, or
    2. because of the speed at which results are needed (IETF working groups often mean slower standards development), or
    3. because people want to avoid the wide participation which IETF working groups get.

User requirements

Common to most IETF meetings is that the people are technically oriented, and the discussions are very technical. User needs and user requirements are not highly valued, unless it is the needs of technical people like network managers, etc. Sometimes, user needs are discussed, because one of the technical people at the meeting happens to understand the needs of ordinary users, but often user needs are not discussed. An example, among others, is that discussion about activities against spamming seem to be more oriented towards protecting mail server managers from problems with spamming than protection ordinary recipients of the spams.


Applications Area Open Meeting


Why does it take such a long time to get an IETF draft approved? Keith Moore's answers: The applications area is a large area, and the stages a draft has to go through are many: Review by the working group, by the area manager, by the IESG last call, by the IESG, by the RFC editor. A common reason for delay is disagreement of who is waiting for whom. At each stage, the document may have to be sent back to the editor for further changes. Moore is trying to reduce the time by performing some of these stages in parallel in some cases.
   Current status of last calls is shown at
   Mailing list for general issues in the IETF applications area:
   To get faster handling of a proposal, one should send a copy of submission of a document for IESG last call, to Steve Coya at the same time as to the area manager.
   Then there was discussion about charters of working groups. Keith said that he requires that a group defines its scope before it begins developing standards. He has had experience where group members had different ideas of the scope of the group and did not recognize this until too late.
   Keith asked which participants were willing to help him by reviewing drafts. Half of those present put up their hands. If you want this, you should write to him and explain which area you are willing to review drafts in.

Security in Application Protocols

Many people devising new applications layer standards have problems with security issues. Every new application protocol tends to define its own authentication methods, it might be better if all could use a common mechanism.
   I pointed out that a method of authentication and authorization, which is more and more commonly used, is that the server sends an e-mail to the requester, with a transaction ID in the subject, and the requester replies "yes" with the same transaction ID in the subject of the reply (possibly preceded by "Re: "). Is there any need for IETF work on standards for this method?
   I also pointed out that different groups may have different requirements on an authentication/authorization standard. As an example, in the USEFOR group, there has been a very long discussion about authentication of CANCELs and SUPERSEDEs. They seem to want a method which allows you to cancel your own messages by only identifying that you wrote that canceled message, but not by identifying yourself in a secure manner. Thus, that special requirement might mean that they would not accept an authentication standard, if it does not support this functionality.
   POP has a password change protocol which includes sending open passwords over the net. Should we allow such bad security? Yes, said some people, since this is mostly used inside Intranets, where security requirements are sometimes lower. No, said some people, IETF standards are mainly for use in the Internet, not inside Intranets. Several other people commented on clear passwords sent across the net.
   Dave Crocket said that a large problem in the IETF applications area is that it is so very difficult to make progress in the area of security features of application standards. Maybe this is because we have too strong requirements of quality on security methods? Maybe we should define things, which can get accepted into the standards, even if they are not perfect. This issue is obviously very controversial, lots of people had opinions on it.
   Someone said that applications standards group should take responsibility for their own security, not just expect security people to do this for them in separate security standards. Someone said that by not accepting not-perfect solutions, we are in practice getting even less good solutions, because nothing better is accepted.

Back to table of contents


Finding Stuff


Specify a BCP (=Best Current Practice) on the best methods for searching, locating and discovering things. This is intended to be used in other standards and by people who want to find things easier.
   The group will not develop new protocols, but look at existing methods. The group will not discuss requirements, and not the philosophy of naming.
   The result could be taxonomy and applicability statements on different protocols. It might also (less important) describe how mechanisms can or could work together.
   By discovery is meant searches which can be handled by bootstrapping, broadcasting, solicitation or waiting for responses to advertisements. They are typically unbounded.
   The different terminology used by different services could be described and correlated. The difference between a search and a lookup: When you perform a
lookup, you have a key, and want to find the item which fits the key. When you perform a search, you have partial information, and want to find items which fit your description. The result of a search is sometimes used for a lookup, and will finally result in an access.
   The layering is not exact. When you perform a
lookup of a URN and get a URL and then access that URL, that access will actually include a DNS lookup. In general, lookup is usually simpler and faster than search.
   Some people say that previous attempts at doing this has failed, but other people said that a good result would be so valuable, that it is worth a new attempt.

Overview of existing protocols:

LDAP   A directory system, which allows to store objects with attributes chosen from a schema in a hierarchical tree structure. The data base can be distributed, so that different servers handle different branches of the hierarchical structure. Other servers can cache data, which they do not have primary responsibility for. Access using ASN.1, a controversial, complex but powerful data formatting language.
DNS SRV RR   An experimental standard, but many people want it to become a proposed standard so that other people can use it in their standards. The author said that he had to remove applicability statement to get it accepted as an RFC, but now people will not allow transition to a proposed standard unless there is an applicability statement. Provides a lookup service using DNS to find things, but has modified DNS with things not supported by normal DNS clients.
SLP   Provides discovery, a simple search, registration of services, is dynamic, returning results in seconds. It does not use a server-server protocol, is not general purpose. Limited to registering and looking up services. Could use an LDAPv3 backend. Works in the absence of other services.
SDP/SAP   Protocol for finding sessions. The information is thus transient, comes and goes, typical life time is a few days. Comes from the transport area. Will probably soon go to experimentation. SDP=Session Description Protocol, SAP=Session Announcement Protocol. When you join an MBONE session you need a multicast address to find the session, and this can be done using SDP. Based on multicast, so you need a multicast address to use it. Work is ongoing on security/authentication. It is dynamic with fast updates.
GENA/RVP   Event subscription and notification service. Operations are SUBSCRIBE, UNSUBSCRIBE, NOTIFY, POLL.
   Delivery can be done synchronously and asynchronously using TCP or UDP.
   RVP extends GENA with DAV resource properties. Properties can be conveyed through XML.
   Applications: Status tracking, location discovery, notifications, for example printer notifications. Before using this service, you get an initial URL using various services.
WWWSeeker   Uses a centralized data base, see draft-rfced-info-morts-01.txt. Task: If you tell me information about an organization, I will be able to lookup their web site. Supports use of SRV to find a web site, and might support WHOIS or RWHOIS or WHOIS++. Available for testing:
   Database update code is available for non-commercial use.
DASL   Search for folders and other resources satisfying certain properties.
URN   Naming resources, and resolving the names to resources. The names are meant to be more stable (persistent) than URLs, and the same URN might resolve to different URLs providing the same resource from different places. A URN can not be reassigned to new uses. There can be different URN servers for different URN name spaces, using different ways of organizing the information.
RWhois   "Rwhois" is short for "Referral whois", a distributed, hierarchical system for information discovery, retrieval and manintenance.
I did not catch which service this description refers to.   Search and lookup of applications, not for discovery. Used in small local environments. Began for static information, but is being extended for dynamic information.
ACAP   Services that you can contact are manually configured by the users. Provides a unified view of services to lookups from different places.

John Klensin said: Almost all the protocols you have listed have actually been used, or said to be useful for, almost all kinds of searches and lookups.

   Category issues:

  • Scalability
  • Administration Issues
  • Configuration requirements
  • What network services are required
  • Security/access control
  • Original purpose
  • What it is good for versus what it could be used for
  • Updating of information which changes with time
  • Bootstrapping: How do you find the right server for each of the services, in order to start using it

Do we need a working group for this? This could give a central point of contact, but it is not a typical IETF working group.
   Mailing list:

Back to table of contents


Event Scheduling


An Event is a message sent to a host, triggering something to happen. There is no agreed and consistent definition of what an Event is. This is done by many different systems and standards today. No one has ever tried to make a unified solution to this before.
   Issues: Notification mechanism, Notification management, Latency, Intermediation, Delivery constraints.
   Security constraints: Trust management, subscription security, subscriber verification, identification of senders and recipient, send to everyone in a group except a certain person, getting accepted by firewalls, delegation of rights.
   Scenario: Web Portfolio Manager: Triggered by update 15 minutes after stock prices change, Portfolio server computes total value of portfolio, etc.
   Who might use it: Web Authoring (WEBDAV), Internet Printing, Presence, Buddy lists, Instant messaging.
   Additions might be developed for SMTP, NNTP or HTTP, or a new protocol might be invented. SMTP gives working delivery system, mailing list handling, but requires stylized messages, get ideas from Delivery Status and Message Disposition standards. NNTP is flooding-oriented, newsgroup subscription, each article has a unique Identifier. HTTP at first seems an unlikely candidate. But the syntax already supports intermediaries (proxies).
   BLIP, SIN and SGAP are existing notification protocols, SIP (Session Invitation Protocol) and RVP (RendezVous Protocol) are also of interest.
   More info at and draft-khare-notify-01.txt.
   A new IETF working group with the name NOTIFY is planned. Charter to consider Latency, Delivery, Initiation, Constraints, Notification Management. Out of scope: Authentication scheme, Message transformation functions, Schema-specific notifications.
   It is easy to sell the benefits, not so easy to sell a mechanism.
   In the discussion, many people said that the scope was too wide and the issues too diverse, and that the group should limit its scope.

Back to table of contents


IMAP Extensions


Charter: Deal with extensions of IMAP4 (Internet Mail Access Protocol) for:

  • ACL,
  • Sorting,
  • Threading,
  • Message-level annotations.

Changes to the base IMAP specification will not be considered in the new group.
Access Control Lists (ACL): Identifiers should be UTF-8 instead of ASCII, mandate union of positive rights minus union of negative rights, identifiers starting with "/" reserved for ACAP groups, don't alter tying of rights. Discussion: Cannot be implemented with the normal Unix access control system. There was a very long and complex discussion on this issue. For example, Unix systems can be configured so that any change to Mary's rights will automatically trigger the same change to John's rights; how can this be communicated to the IMAP Client?
Sorting: Issues are client-specific comparator, persistency and notification (notifying the user that incoming messages have been sorted into a certain place), threading, scroll bars and paging. A thread is a tree, not a flat list, someone said. Threading requires a registered threading algorithm, there are several different algorithms, like subject sorting, or References-type threading.

Back to table of contents


MIME Enabled, Textually Accessed Directories (METAD) BOF

Yet another directory access protocol? The proposers claim that present directory systems require too much software investment to implement.
Lightweight: You should be able to connect to a port and type a query and receive an intelligible reply (like Whois and Whois++).
Generic: Few rules about what an object must look like or what policies (hierarchies) it must adhere to.
   Must be able to support
gatewaying to traditional directories and access protocols.

  • Should support both attribute/value and complex format representation for the data (complex formats do not require a complex data model).
  • Support, but not require, hierarchical data.
  • Query routing in loosely coupled networks.
  • Ability to write a 5-line client (e.g. Java Applet).
  • Base functionality independent of application.
  • Extensible for particular applications.
  • International support (character sets, etc.)
  • Security (some subset of authentication, using existing technology).
  • Internet scalable to data bases with millions of records.

Whois++ has many good ideas, but also shortcomings. But ideas from it should be used in the new standard. The new standard should be simple, not a dumping ground for every function anyone wants to have in a directory access protocol. LDAP requires much too complex clients, and has shortcomings in supporting collections of loosely collected servers.
   Discussion: Do we really need a new protocol. If it so simple, can it not be provided by an ordinary search server supported by a web page.
   Show of hands: About 20-30 people liked the idea, and about 8-10 people were willing to work on the proposal.

Back to table of contents


Simple Workflow Access Protocol


Communicate over the Internet between heterogeneous workflow systems, support long lived units of work for Internet access, control, monitor and notifications between requester and workflow systems and instances, lightweight and extensible protocol.
   They aim at only standardizing communication between workflow servers, because at present the client-server protocols in this area are proprietary. I suggested that they should also develop
a simple protocol for talking to clients. It could be implemented through simple extensions to an ordinary e-mail client. This would be valuable for small companies, who do not have their own workflow server, to participate in workflow activities of larger companies. Their interest in this seemed to be limited.
   Chris Newman pointed out that
the iCalendar group has a task object which seems similar to the workflow area.
   Operational requirements:

  • Invoke a generic service to create a workflow instance,
  • Get current status of an instance,
  • Provide data values to an instance,
  • Pause or resume an instance,
  • Retrieve preliminary results of an instance,
  • Subscribe to a service to receive notifications from a workflow service or an instance,
  • Receive events from an instance,
  • Protocol must be extensible,
  • Protocol must address performance and security issues.

Not in scope:

  • Exchange of process definitions,
  • Statistics or monitoring,
  • Unification of services into a generic service,
  • Transactions,
  • Administration functions such as installation or general management of a service,
  • Presentation to humans or other types of format layouts.

Several people said that this is related to many other ongoing Internet existing or in-development standards. The new group intends to check on this work to support co-working and avoid duplication of efforts. There was a long discussion of whether HTTP or SMTP or both would be suitable protocols.

More info at

Back to table of contents


Presence Information Protocol Requirements BOF


Because of parallel sessions, I could not go to this meeting, but here is (abbreviated) their textual presentation as submitted before the meeting.
   PIPR deals with the requirements for a protocol for interoperable presence and instant messaging applications (colloquially, "buddy lists"). These applications have recently emerged as an important medium of communications over the Internet. Typically, these applications provide the following:

  1. A means for users to find, retrieve, and be notified of changes in the presence information (e.g. 'online' or 'offline') of other users, and
  2. A means for users to deliver small, simple messages instantly to other users.

   These applications currently use independent, non-standard and non-interoperable protocols developed by various vendors, thereby dividing the users into disjoint islands of communication. This severely restricts the utility of each application. The goal of a Presence Information Protocol (PIP) is to define a standard protocol so that users can be aware of each other's state and can send instant messages across the Internet, without concern for whether the other parties have presence and instant messaging applications from the same vendor.

Back to table of contents


HTTP Next Generation


Again, a session I missed, here are quotes from their written presentation before the meeting.
   The HTTP-NG proposal which is the basis for this HTTP-NG BOF at the IETF Chicago Meeting, August 23-28, is to
factor HTTP into three layers, to obtain the well-known benefits of modularity in general and, in particular, better structure the large and growing family of uses of HTTP and HTTP-like protocols:

  • The lowest layer is a transport abstraction that accommodates a variety of stacks of transport primitives and transport transformers (filters); a particularly interesting transport filter is the webmux, which is intended to provide a better impedance match between TCP and the transactional nature of the middle layer.
  • The middle layer is an efficient wire protocol that brings the benefits of interface technology into the Web.
  • The highest layer is an expression of the Web as an application of the lower two layers.

We expect this three-layer structure will bring many benefits to the Web, including easier evolution of the protocol standard, interface technology that would facilitate Web automation, easier application building, and so on.
The purpose of the BOF is twofold:

  • to share the experiences that we have gained in the W3C HTTP-NG
  • project over the last year in working with a prototype of a new model for HTTP based on a distributed object architecture with Internet constraints in mind; and
  • to gauge the interest in moving the HTTP-NG protocol design work to the IETF and to initiate work on WebMux, the HTTP-NG wire protocol as well as mapping HTTP/1.1 features into this new framework. The goal is to turn the initial set of rough drafts into robust standards track specifications.

Current Status

We have currently an initial set of Working Drafts that describe the proposed HTTP-NG architecture and a rough prototype which implements most of these drafts. We plan to have some real performance measurements by the time of the BOF based on Web data produced by the W3C Web Characterizations Group.
   We feel that the time is right to move forward with the HTTP-NG work and directly involve the Web community and the Internet community in general and that there is no question that this should happen within the IETF.

Working Drafts and Notes

Here is the list of current drafts to be discussed at the BOF:

Back to table of contents


Internet trading, Open Trading Protocol (IOTP)


Issue: Sending transactions, like those produced when you are doing VISA payments, over the net.

Mailing list:
Archives: htttp://
Web site:

IOTP = Open Trading Protocol. This working group has many of its meetings separately from IETF, which is not common or accepted practice for IETF groups. Future meetings at CyberCash in September, at Hitachi in Japan in November and at IETF in Orlando in December 1998. Many large and small companies are partners, like banks, software houses, etc. (Warning: The acronym OTP is also used, but this acronym has an alternative meaning, One Time Password SALS Mechanism.)
   Issues: IOTP Digital signatures, IOTP architecture, IOTP over HTTP, SET over IOTP, Secure credit/debit over IOTP, Electronic Cash over IOTP. There are other ongoing standards developments covering similar goals, see figures below, which shows why IOTP does more than other standards.



Back to table of contents


Detailed Revision of Messaging Standards (DRUMS)


The intention of this group is to develop revisions to the very old Internet e-mail standards SMTP (RFC821) and RFC822. The group is not to invent new features, only to clarify unclear points and make the standards more complete and accurate. The group has been going on for a very long time, and is now in its final life throes boggled up with curious technical details, like should ABNF allow comments to start in column 1 (which no standard uses today, to my knowledge).
   Just now, the most controversial issue is whether to mandate support for the VRFY operation in SMTP. This operation checks if a certain mailbox exists in a server. It is useful for testing, but has some security risks, so if it is mandated, we will at the same time say that an implementation can disable it.
   I have never encountered an IETF group meeting where there were so many jokes and laughs, probably because people know each other very well by now and feel that the issues have been discussed too many times. (Typical joke: Since we cannot agree on this response code, we could change it into a 600 code! Only Internet protocol experts will understand this joke!)
One really marvelous invention in the new standard is that it has two grammars, one accept and one generate grammar. The accept grammar includes certain constructs which you should not use, but which does occur in real usage. Advantage: The Internet golden rule is easier to follow consistently. Disadvantage: Some people will misinterpret the standard and generate things which only are in the accept grammar, saying to other implementors: The standard says you must understand this!
   One can only hope that other Internet standards will do the same.
This is mostly needed for old, much-implemented standards, where there is experience with how reality inevitably differs from what the standards text says. In e-mail, however, one very important "don't generate if you want good interworking rule" is not included, the rule not to use spaces or other quoting-requiring characters in e-mail addresses. Some implementors are using this, and it is of course very nice and user-friendly, so it is still allowed. At this meeting, it was agreed that there is no requirement to give precise definitions of the semantics of features which are in the accept, but not in the send grammar.
Another useful invention is that e-mail will now standardize use of the "References:" header to handle threads in much the same way as Usenet News is doing. This is important, since good thread support is very valuable for users. I am really surprised that this radical proposal has been accepted in this very conservative group, but I certainly have not complained.
   One of the most important (!) results of drums is that the new e-mail standards now specify the syntax for white space and comments in e-mail headers more exactly. In earlier standards, it was not clearly specified where comments and white space was allowed or not, which had caused some crashes in communication between implementations, which implemented this in different ways. Today, most implementors know to accept almost anything in incoming messages but be very conservative in where to put comments, in accordance with the golden rule. The safest place for comments is at the end of header field values, even though the standard allows more than that. (Comments in RFC822 header fields are enclosed in parenthesises. Example: "The Johnny Automatic Responder <> (do not reply to this e-mail address)".)
   At this meeting, there was a very long discussion about bare CRs and bare LFs in RFC822 text. Should they be allowed (which RFC822 requires) and should they *not* be treated as line breaks (which also RFC822 requires).
   There is discussion about the new SMTP document, which includes both a strict SMTP standard, and some advice about proper behavior of mail agents, which are not always so strict. Some people wanted this separated into two documents. This will not be done, but the text will clarify the distinctions.
   Flag date: Saying that a certain requirement in a standard will be loosened or tightened at a certain future date. Not accepted, because time changes, we do not know today what the world will look like at the flag date time. There was a long discussion on an important technical issue: How to shut down SMTP connections. We agreed that the client SHOULD send a QUIT SMTP command, and the client SHOULD wait for the server to shut down the TCP connection after the QUIT. This is related to avoiding time-out waits in pending TCP stacks in a way which I did not quite understand, but which some people felt to be very important.
   We then discussed a problem with firewalls. Firewalls sometimes tunnel EHLO to the SMTP server behind the firewall, and this SMTP server then promises support for things which the firewall will reject. This is not quite correct of course. If a firewall does not accept certain SMTP commands, it should modify the EHLO response!

Replacement for RFC822
Replacement for SMTP

Back to table of contents


Short Mail-Related Extensions Proposals



(draft-lindberg-anti-spam-mta-04.txt) Main idea is to not relay other people's e-mail, only relay your local user's mail and only accept incoming e-mail where the sender has a valid mailbox, which can be validated through the DNS. This will make spamming a little more difficult, but spammers have already learned to circumvent it. Other proposed ideas: Refuse too many mail in a short time from the same sender.
   Some people present said it was not ready to become a BCP (=Best Current Practice) because we do not have enough experience of how well these features work.

Mail Submission

(draft-gellens-submit-11-txt) Today SMTP is used both for submission and relaying of e-mail. This proposal wants to separate out submission into a separate protocol (port 587 has been registered for this instead of port 25 for mail relaying), which can do some more checking than for relaying. Recommends some kind of authentication, to ensure fully qualified domain names, should reject invalid address syntax.
   Discussion on should it become BCP, Proposed standard or Experimental standard. IESG will make the final decision on this.

POP 3 Mail Downloading Protocol

(draft-gellens-pop3ext-07.txt) on features to announce optional command extensions and behavior variants, also adds some response codes, gives better syntax definitions, solves problems with more than one client trying to use the same mailbox at the same time, but mainly tries to keep POP clean and simple and not make lots of new developments.

Auto-Submitted, Supersedes and Expires E-mail Headers

(draft-ietf-mailext-new-fields-13.txt) on three new header fields. Seemed to be agreement to accept it as a proposed standard, but rather few (3-4) planned implementations. Some controversy of whether Supersedes should more clearly differentiate between hard and soft supersedes. Some discussion that security considerations should more clearly specify the risks with this.

Replacement for X-sender

(draft-newman-msgheader-originfo-05.txt) header to indicate the original sender's account, even if this is not an e-mail address you can send to.

An e-mail Header Registry

(draft-ietf-drums-MHRegistry-03.txt) Consensus that such a header registry is to be established, but the wording of the proposal should be discussed in a new mailing list, but not a new IETF working group, before making it a proposed standard.

Support of not-Fully-Connected Servers

(draft-gellens-on-demand-05.txt) proposes a service to allow servers which are not connected all the time to the net to connect and download e-mail for several users in this server.

Gatewaying of Security MIME Body Parts

(draft-freed-gatesec-02.txt) discusses how gateways should handle security body parts, either pass them unchanged, or, if they must be modified, replace the signature with information that it has been removed.

Types Parameter for Multipart/Alternative

(draft-lundblade-lpass-mult-alt-01.txt) proposes an additional parameter to multipart/alternative, listing the types of the alternatives, to allow faster selection of body parts by receiving clients.
   Discussion: Also language is often different between alternative body parts and should be included.

Authentication Response Codes

(draft-newman-auth-resp-00.txt) proposes different response codes for different reasons for authentication failures in e-mail: Ask user to re-entry password, give up, ask user to change password, require encryption, too weak authentication, transition to more secure authentication required.

Do not deliver after a certain time

(draft-newman-deliver-00.txt) proposes a way to specify a time limit, after which delivery of a message should not any more be attempted.

Meta-Data Content Disposition type

(draft-newman-mime-cdisp-metadata-01.txt) proposes a new value for the Content-Disposition header, to indicate that this body contains meta-data about another body part, and is not of interest in itself. Usually these body parts are not shown to users, but handled by the software. Example: Resource fork body part for the Apple-Double format.

Tunneling ESTMP

(draft-freed-bsmtp-01.txt) proposes a way of tunneling ESTMP through non-ESTMP compliant servers.

Soft and Hard Line Breaks in E-mail

(draft-gellens-format-00.txt) proposes to distinguish between those variants of text/plain which have hard line breaks, and those which send soft line breaks between lines and hard line breaks between paragraphs. At present, many mailers wrongly send whole paragraphs as single lines in e-mail, which causes problems. The proposal has a detailed specification of how to handle quotes (leading "> ") when responding to messages in the new format. A new parameter is proposed to Content-Type: Text/plain.

Back to table of contents


Message Tracking Protocol


(This figure shows the proposal, not the finally agreed solution)

A proposal to specify a way for every MTA which a message passes to send a notification to an "Event Repository" about what has happened to the message. Also events after final delivery are to be tracked, like forwarding and resending. This seemed to very controversial. Discussion on political issues like who are allowed to access the event databases, end users or only mail administrators. And tracking behind firewalls might display confidential information. Anyone who knows the Message-ID of a message would be able to check the tracking of that message, which was said to be a security risk. And for messages sent to Blind Copy Recipients, the other recipients would be allowed to trace the BCC recipients! It might be better to only allow the senders to query the trace servers for their own messages. Use of cryptographic security was proposed by some people at the meeting.
   I felt these complaints were maybe too harsh. This is, presumably, not a mandatory protocol, so those who do not want to reveal information would simply not send the tracking information. And if you want to create unguessable Message-IDs, this is not very difficult to generate.
   Issues: Should you get this only if you request it when you send a message, or should you afterwards be able to query the position of any message, which you have sent. A lot of discussion of a simpler alternative, that you would just extend the DSN (Delivery Service Notification) standard to allow the sender to ask for DSNs at every step, and not only at final delivery.

Back to table of contents


Authentications, Authorizations and Accounting BOF (AAA)


Goal of the proposed IETF working group: To understand the issues and direct the IETF in the right direction, and to look at existing proposals DIAMETER and COPS, or, if needed, invent new protocols.

Bandwidth Broker Model: To broker agreements between Internet users who ask for various amounts of bandwidth, typically when some of them need a very high bandwidth for some particular application at some particular time (example: on-line x-ray investigation). There is a problem of trust/distrust. RSVP can be used.
   There is a difference between Intra-Domain and Inter-Domain brokering: Intra-Domain has trust and common or shared databases between peer servers, while Inter-Domain has distrust and public versus private policy. A bandwidth broker is a resource manager, which manages demands and controls resource usage.
   IKE: Authentication between connecting hosts or gateways, not very much of end-to-end authentication. No support for legacy authentication protocols, little flexibility. Will keep strong security of public key authentication, but allow use of existing authentication methods. All that is needed is a new authentication identifier.
   DIAMETER is used by mobile units to register access to network services.
   PINT: User supplies phone number in a web form response, sales person calls the user at this phone number. But if you make a call, you are responsible for it, you pay for it, you are responsible if the call is illegal or improper. The phone network must authenticate the requestor, and authorization may be needed.
   RAP: A protocol to commuicate decisions to a device between different domains. In this way, IETF does not define policy or limit the technically viable policies. The protocol is lightweight and RSVP-compatible. Client is esy to implement, the protocol scope is manageable. The protocol allows revocation of existing resource-using state (example: Resources only available between nine to five). RSVP's soft-stae and merging does not effectively track states. Does not do accounting, but can export information to acocunting systems. It tries to isolate the decision from the policy itself.
   Opposition from meeting attendees: It is not true that there is no end-to-end security services available in the Internet today. Such services exist, but are not widely used.
   SS7: Device Control Considerations. Diameter-based proposal for signaling transport and device control.

Documents on SS7 and Diameter:

      Signalling Transport: draft-bell-signaling-00.txt
      Device Control:

NAS: Accounting Management: Purposes for accounting, inter-domain vs. intra-domain accounting, scaling and reliability issues. Attemps to look at the general problem, not NAS-centric view. Requirements: Flexibility, Scalability, Security, Record Transfer, Record Information. Requirements have been evaluated against RADIUS, TACACS+, SNMP, SMTP, DIAMETER.

Back to table of contents


Cooperative Information Systems


The week before the IETF meeting, I participated in the COOPiS'98 conference about Cooperative Information Systems.

Back to table of contents