Applications IETF
March 2001 Notes

Table of contents

• Applications Area General Meeting
• Presence and Instant Messaging
• Application Exchange WG
• Content Distribution (caching control, etc.)
• Web Intermediaries (Caching control, etc.)
• Internationalized Domain Names
• The future of URIs
• WebDAV based groups (group maintenance of document collections)

Introduction

General Notes

• The many different groups working on instant messaging and presence protocols, using different approaches.
• Also several active groups on further development of WebDAV.
• And several groups discussed whether to build new protocols on top of BEEP/BXXP. This protocol foundation has previously been known under two different abbreviations, BEEP and BXXP, but at this meeting, BEEP was the mostly used acronym, perhaps because it is more easy to pronounce.

Back to table of contents @ Other meeting notes

Applications Area General Meeting

Chairs: The application area directors, Patrick Fältström and Ned Freed.

This meeting is usually mainly a walk-through of the status of each working group. I will here only report on some of the reports.

BXXP is the working group to develop a new application framework for two applications to run multiple parallel sessions over a single TCP connection. They are ready and published as RFCs except for a specification of mapping on top of SMTP, which is still not ready. (I do not quite understand why you need to map BXXP on top of SMTP, but I guess they have reasons for this need.)

LDAP has had a lot of discussion regarding single-master and multiple-master replication.

The USEFOR group has had lots of discussion for many years, but not produced many result documents. The area directors threatened to close it down, unless it starts producing documents sent to the IESG for approval as standards.

The previous working group on Web Replication and Caching (WREC) is closed and replaced by a new working Web Intermediaries (WEBI) is replacing it.

Application Protocols Security Design

Jeff Hodges <jhodges@oblix.com> made a presentation followed by a discussion.

How can you use existing tools to add security to new protocols? Simple answer: Design a command to start TLS below your application.

Important is to know which threats you anticipate, write scenarios of possible threats:

• Eavesdropper
• Impostor
• Hijacking servers through the net or by stealing the data base disks
• Denial of service

Back to table of contents @ Other meeting notes

Instant Messaging and Presence

Do you believe that "Instant Messaging and Presence Protocol (IMPP)" and "Presence and Instant Messaging Protocol (PRIM) " means the same thing? Wrong! The first is a general group, the second is one of several alternative solutions. IETF is working on several alternative standards in this area:

PRIM

Presence and Instant Messaging Protocol is a minimalist approach as a simple protocol, directly on top of TCP, self-contained.

SIP

This is a more advanced proposal.

APEX

This aims at using BEEP/BXXP as a basis.

CPIM

A standard for interoperability between different IMPP protocols.

There were several different sessions on Instant Messaging, representing different approaches to how to establish interworking between different instant messaging systems. I was not able to go to all the sessions.

The Instant Messaging and Presence session

Issue: What security features should be mandatory. Proposal: Reception of multipart/signed, and sending of S/MIME multipart/signed.

Discussion: We do not know if S/MIME will really succeed. S/MIME has existed for several years without getting widespread acceptance. Should we really decide to assume that S/MIME will succeed?

Conclusion was that reception of multipart/signed will be mandatory, but not sending of S/MIME multipart/signed.

Issue: Routing loop prevention. Proposal: Decrement a hop count. This requires that hopcount element is outside of the signed portion of the message.

Issue: Standard date format, RFC1123 or ISO format. Proposal: RFC1123 style date, e.g. 01 Dec 1994 16:00:00 GMT (only GMT allowed). Humming did not quite clearly indicate which date format is mostly preferred. Discussion: For which format do we have experience that it works? A lot of people had opinions on this. ISO format is easier to sort. Its full generality is very complex, so if we want to use it, we should use a subset of it, the same subset used in the "Calendaring and Scheduling" standards work. About 10 people voted for the RFC1123 format, about 20 for the ISO format, most of the people present did not vote for either alternative. Someone said that the field name should not be "Date:" if it is not the same format as for e-mail. The field was renamed "Date-time" to avoid this problem.

Issue: Payload content for common presence information. This can be text, picture, or something else. Not very clear what is allowed and what is meaningful. So pictures (like smileys) will be moved to extensions, text field will be kept.

Issue: Geographic information in standard attributes? Resolution: This will be an extension, not a required attribute.

Issue: Payload for presence information, use rfc822-style or XML? This was related to security in a way I did not quite understand. Advantage with XML is that the same syntax can be used for subfields, RFC822-style requires new syntax for subfields. Resolution: Use XML. Will there be a MIME wrapper around the XML? Or full MSG-FMT or just a raw MIME type? Needs more thought.

Presence and Instant Messaging Protocol

PRIM is a combination of four different proposals for instant messaging, out of the ten original proposals when this work was started.

This was the group for the PRIM solution. Some people wanted to discuss the pros and cons of PRIM versus other solutions, but the area director said that this group should discuss how to make PRIM a good protocol, not to compare it with the other alternatives.

PRIM is a simple, minimalist approach to protocols for instant messaging and presence.

PRIM messages have separate PRIM.Message-ID (Unique ID for this message) and PRIM.Conversation-ID (Unique ID for this conversation).

Issues: What happens when a mobile user moves from one area to another area. Will such a user be moved to a new presence server? Will instant messages still be able to reach that user?

SIP for Instant Messaging and Presence - SIMPLE WG

SIP for Instant Messaging and Presence Leveraging Extensions, is yet another group working on standards for instant messaging and presence.

draft-rosenberg-impp-im-01.txt and draft-rosenberg-impp-presence-01.txt are the drafts to be discussed at this meeting.

Issues: Can you mix pres:, im: and sip: URLs? What happens when non-SIP URLs occur in SIP messages?

SIP will not efficiently be able to carry large messages through SIP proxies, but SIP can establish separate, direct connections to transmit large messages. Shorter messages can be sent in a SIP stream.

Should messaging be handled in a session-oriented or session-less method? This caused a very long discussion. INVITE can be used for messaging, people will do this if we provide the opportunity, even though INVITE was not primarily intended as a message-transfer tool.

Back to table of contents @ Other meeting notes

Application Exchange WG

This was one of many sessions during this and the previous IETF meetings, which was an outcome of the interest in standards for instant messaging and presence protocols. This particular group aims at specifying a general purpose mesh service for loosely-coupled Internet applications. The outcome of the work in the group can be used in one of the Instant Messaging and Presence tracks, the CPIM track. The work is based on the BEEP/BXXP protocol.

Of special interest to this group is access-control and rendesvouz-by-subscription.

Use of apex for client server applications

One person said that APEX could be used for file sharing, bug/FAQ databases, CPU sharing, Multi-user Games, Intelligent Agent Support, Conference Call Support, etc. but that this required APEX supports for client-service applications.

There was a long discussion of hierarchical versus non-hierarchical service names. The speaker explained that he starts with a hierarchical name (URI) and uses this to lookup a non-hierarchical name to be used in the continued service. I did not quite understand why this was needed. The speaker said that this was needed because the XML syntax for the "action=" does not allow hierarchical names. A particular domain (hierarchically named) provides a flat name space.

Adding Application-Level Multicast Services to APEX

Multicast = one-to-many or many-to-many delivery. It is based on some kind of anonymous recipient ID, not an explicit recipient address as for normal transmissions. The disadvantage is that if you want to distribute the same information at the same time to lots of recipients all around the net, then the network load will be much lower with multicasting than if everything has to be sent separately all the way from the source to each of the recipients.

Multicast in IP has been defined for many years, but has never succeeded in getting much deployment. It requires modification in the IP routers, which is a disadvantage. It user rather weird technical methods, someone said at the meeting. Multicast in APEX does not require any changes to the IP routers. There are proprietary solutions for multicast on the application layer, but no vendor-independent standard. Multicasting based on APEX might for example be useful for content-distribution.

Issue: How can a user, whose ISP does not run any APEX server, join the APEX community. Will not the access-control methods used by APEX prevent such a user from joining?

Content Distribution

This group is a continuation of work, which was previously called "Web Replication and Caching". The main aim is to reduce the load of far-distance downloads by providing local content repositories, and also provide, together with the local content repositories, additional services, like virus scanning, local search engines. They are more oriented towards co-working content distribution networks.

Since it is not yet an official working group, you should search for "cdn" in the middle of IETF draft names to find the drafts pertaining to this work.

One speaker complained bitterly: There are several patents, suing each other, and making work complex for IETF standards work. The patent system is screwed up. People unreasonably get patents for well-known ideas and methods. Lawyers have unreasonable concepts of what is novel and patentable, causing much problems and stopping technical development and standards work.

Model documents describes taxonomy (terminology) - taken over from the WREC group. The group is trying to move model concepts to the model document, and remove the model introductions from other documents, which can instead refer to the model document.

The work had only a one hour slot, which caused the people making presentations to skip through their overheads at a horrendous speed, often only talking a few seconds on each page.

Issues much discussed during the meeting was contract, business agreement, quality of service promises, advertising of content and content handling facilities, distribution of content based on cost, peer-to-peer-networking versus paid-for services with accounting systems, etc., etc. Must all companies participating in content distribution have bilateral contracts with all other companies, or can some kind of global contract be used for many co-operating companies?

Back to table of contents @ Other meeting notes

Web Intermediaries Working Group

The group intends to specify something they call "delta consistency" which is less than strong consistence (polling every time an object is requested, or updating by the master every time an objects is changed). It is based on providing a freshness guarantee. The term "delta consistency" may be confusing, since it may be misunderstood to mean "delta encoding" (=sending only changes, not whole documents) which is not the same thing.

Object invalidation can be driven by the server (pushing invalidations on clients) or by the client (polling for updates to a volume of objects). Both will be combined in the standards produced by this WG.

Saying that a document will be valid for a week does not mean a promise that the document will not change in a week, it may change, but the old version may still be useable for a week. It is a problem that people do not understand this distinction.

WCIP wants to define general methods, which can be used over several different transport mechanisms, not only common HTTP. They will define a general model, and a mapping of this general model on HTTP, but it may be mapped on other transport mechanisms than HTTP such as BEEP/BXXP.

Should the client register objects of interest, and the server send only invalidations of those objects. Advantage: Less traffic to the client. Disadvantage: Not scalable, does not work for IP multicasting, complicates the protocol. Instead, they discussed providing "volume invalidation" where an invalidation is valid for a set of objects, a "volume".

Telling all clients at the same time that "now this object has changed" can cause lots of clients to request it at the same time, causing a flash load which the master server cannot handle.

Instead of URLs, they may invalidate events. An "event" can cover multiple objects, but the client must be able to interpret to event to know which objects have been invalidated.

Back to table of contents @ Other meeting notes

Internationalized Domain Names

This is both one of the most important and one of the most difficult tasks facing IETF just now. It is important, because if IETF does not make any standard, different incompatible solutions will appear in different countries, causing future interoperability problems for the Internet as a whole.

It is difficult, because different languages and language groups have different requirements which are difficult to support in a single system. Examples of language problems:

• How can a new DNS co-work with older software based on previous DNS standards?
• How can a person outside a country type in a domain name in the language of that country?
• Some languages prefer to order domain names in a low-high order (like DNS today) others in a high-low order, e.g. "foo.bar.cn" versus "cn.bar.foo".
• Take an homonym, like "fire" in English meaning something burning or canceling an employment. Suppose a language has two spelling formats, and in one of them the two meanings are spelled the same, and in the other the two meanings are not spelled the same?
  Which domain names are so similar, that two different organizations should not be allowed to register similar names.
  
  Example: In English "abc" and "ABC" are regarded as so similar, that two different organizations cannot register these as different domain names. But should for example "Hexe" and "Héxe" in French be allowed as different domain names? Should the same word, spelled with traditional or simplified Chinese spelling be identical or not? Should an English company be allowed to register a domain name which differs from an American domain name only in that a part of the domain name is spelled "humor" in the American name, and "humour" in the English name?
        Should a German organization be allowed to register "apfel.com" when an American company owns the domain name "apple.com"?
        One solution proposed was that the organization, which registers a domain name, should specify all the alternative variants, which this organizations regards as equivalent. This would mean that the standard need not specify rules for this. If an American company registering the domain name "good-humor.com" wants this to prevent a different English company from registering "good-humour.com" or a German company from registering "gute-humor.com", the American company must specify this when it registers its name!

Someone said at the meeting that draft-ietf-idn-cjk-00.txt gives a good explanation of the problems caused by traditional and simplified Chinese spelling.

As can be seen by these examples, people are perhaps requiring too much of the DNS, and requiring that the DNS include intelligence which is too much for a system like the DNS.

I am happy that I am not a member of this group, it seems to be mired in very difficult problems to solve.

Back to table of contents @ Other meeting notes

Future of Uniform Resource Identifiers BOF

The W3C has been doing some work on clarifying URI standards, and this meeting aims at informing IETF of this to allow for co-ordination if needed.

• There is a long history of unregistered URI schemes and confusion about URL/URN/URI schemes and their registration.
• XML Namespaces are incompatible with relative URI references.
• Interest in this in the XML Protocol Working Group (SOAP).
• XML Core WG maintains the XML namespace, and could consider these issues.
• W3C has started working on Semantic Web Activity.
• A WEB architecture group is being planned.

RFC 2366 is the main document, the URI specification. Worth reading carefully. There is the URN syntax (RFC 2141), a specific URI scheme, which is meant to be location independent, and there is an IANA namespace of registered URIs. There is an IANA registry (RFC 2717) of URI registration, and RFC 2611 on URN name space and registration procedure.

Historical misunderstandings:

• Identification versus Location
• Identity fundamental underpinnings
• Equivalence of Identifier, Scheme, Resource, etc. Are two URI strings identical or not? Are these two URIs referencing the same thing?
• Roadmap of specs, the "Comprehensive standard" exists as an IETF draft.

Questions which need to be answered:

• Is this URI identifying an XML resource, and if so, which ones?
• Is this URI a cached alias for this other one?
• Is this URI some part of this other URI that identifies some collection.

XML software believes that two relative URIs refer to the same thing, even though the base is different.

Must an URI used in an XML document be serviced by its owner?

The "File:" URL is much used, but not clarified in existing standards.

Internationalization of URIs must be co-ordinated between W3C and IETF.

The understanding of the division between the terms URI, URL and URN is not good.

Back to table of contents @ Other meeting notes

WebDAV-Based Groups

When several people are working together on a common set of documents, for example a web site or modules of a large and complex software package, then it is important to control what happens when several users want to edit the same document or module at the same time. Packages for this typically support locking a module, so that only one user at a time can modify it, and merging of two variants of the same document. Packages also often includes versions, a set of modules which work together, and facilities to go back to earlier versions of modules. This IETF working group is developing HTTP-based protocols for handling such work.

The existing WEBDAV standard uses an extension of HTTP to handle this.

WWW Distributed Authoring and Versioning group

This group discussed extensions to WEBDAV on Access Control Lists (ACLs), DASL and moving the WEBDAV standard (RFC 2518) to draft status.

Web Versioning and Configuration Management group

The main technical work is ready, but there is some work left to do on "packaging", organization of the functionalities into packages, sets of functionalities. Some optional features belong together, and a package is a group of optional features which should be implemented together. Some optional functionalities may be included in multiple packages.

Potential packages are "Base", "File versioning", "Client CM" and "Server CM". Below is a proposal discussed at the meeting.

Package Name

Functionality