Applications IETF July 1999 Notes

Table of contents

Applications Area General Meeting

Chairs: Area directors, Patrick Fältström and Keith Moore.

Current working groups

Went through all the working groups. The list below is not complete.

ACAP:

Winding down.

APPLMIG:

Finalization wait.

CALSH:

Alive and well.

DASL:

Alive and well.

CONNEG:

Winding down, waiting for final review from the MIME community.

DELTA-V:

Alive and well, in hand-to-hand combat.

DRUMS:

Winding down, waiting for area directors.

EDINT:

Wandering in the woods.

HTTP:

Finalization wait.

FAX:

Maybe alive and well, maybe winding down. Some late ideas which group has not decided whether to include or not.

TRADE:

Alive and well, taking longer because actual implementations are going on and influencing the work.

IMPP:

All done except notifications, which is being worked on just now.

LDUP (LDAP Replication/Update Procedures):

Alive and well.

LDAPEXT:

Alive and well.

LSMA (Large Scale Multicast):

Winding down(?).

MADMAN (main and directory management):

Finalization wait.

MSGTRK:

Just starting. Some wandering in the woods. Design issues, how can we make it work on the Internet scale.

NNTP:

Wandering in the woods. Basic informational document soon ready, extensions and new protocol: Very unclear if results are coming.

PRINTMIB:

Finalization wait.

SCHEMA:

Winding down.

TN3270:

Some interesting results coming, winding down.

URN:

Finalization wait.

USEFOR:

Trying desperately to get out of the woods. Some new chairmanship may mean the group will get somewhere. Very active mailing list.

WEBDAV:

Winding down, one last specification to get out.

WREC:

Just starting, requirements definition work.

General guidelines

When closing a group, you have to either publish as an RFC, or explicitly decide to cancel, all their current Internet drafts. The IETF secretariat will not allow the group to close down unless all current IETF drafts are taken care of, one way or the other.

When you write to area directors, mailing lists or IESG: Always include the file name of the document you are referring to (version number not needed).

BOFS

CNRP: Charter will soon be ready, looks good.

VPIM: Was not clear if a working group was needed, but have now decided that such a group is to be started. Will look at goals and charter, try to get into some important details.

IMAPEXT: Some issues, on which we are confident, a definite list will soon be available. Nothing terribly exiting or controversial.

LSD-2 (OPS Area): Services that access information from multiple directories which are not under central control. Rescuing the final remnants of the dream of "a" global directory.

Issues

Is there a risk that the authorization group (in the security area) will come up with results, which do not fit the requirements of the application area. Important that more applications area people go to their meetings and check what they are doing. They want us, too.

Working groups should check the official web pages for their working group, and check if there are outdated documents there. If so, you should inform the secretariat, so that these will be removed.

draft-ietf-xxx where xxx is a working group are official working group documents.

draft-aaa-xxx where aaa is author and xxx is a working group is possible for input papers not yet accepted as official working group papers.

URLs for Corba objects?

URLs for telephone numbers?

LDAP is more and more getting used for storing various kinds of data bases.

Back to table of contents @ Other meeting notes

Web replication and caching (wrec) working group

Mailing list: wrec@cs.utk.edu

Introduction: There are lots of problems in getting caches to interwork. Caching does work because of agreements between caches. It would be better if these were standardized. At present, it is even difficult to discuss, because different vendors use different terminology.

There were about three people present who claimed to be cache vendors, and about three who claimed to be cache operators. This group was very popular, about 80-100 people, some who came late had to stand.

DESIRE II is active in this area.

Agenda:

1. Taxonomy/Terminology
2. General discussion
3. Inter-cache document
4. Vendor protocols
5. Charter revision

WREC taxonomy

There is a taxonomy document which can be downloaded. Its intention is to list and organize all issues and concepts, but not offering solutions.

Authentication and privacy: Who do you trust? Legal issues, cooperation may be needed with Internet Lawyers Task force. Will logging infringe on privacy?

Service security: Denial of service, replay attack, stupid configurations, transient copies. There are different privacy issues with transient copies. There is the privacy of clients, whose actions should not be visible in a cache. There is the privacy of providers, some of which are not happy that their documents are copied in various caches.

Terminology: We define some terms differently than in the HTTP/1.1 specification, is this a problem? Examples of such terms: Proxy, Tunnel, Cache, Transparent.

Does transparency mean semantic transparency or network transparency or user transparency? Transparent proxying is either technique or collection of components or something else.

A proxy which rewrites web documents, and delivers them to the user piecemeal, are they caches or rewriting proxies or what?

Automatic configuration systems, where applications on the net configure your browser without your awareness.

Reverse proxy: Does it mean proxying requests instead of proxying responses?

Proxy versus Surrogate proxy versus Reverse proxy versus Accelerator versus Server side portals. "Surrogate proxy" and "Reverse proxy" are almost synonyms, but not quite.

Snooping versus Hijacking versus Redirection versus Interception. This is server-based traffic redirection, not the same as routing in the IP layer.

Cache array versus Diffused array versus Cache cluster = a bunch of caches working together.

Proxy discovery versus Transparent proxy discovery.

Network element: What does that term mean? Something provided by TCP?

Temporal domain versus Persistent Domain. What is the difference? Sparse working set cache.

Inter-cache document

This document was originally not developed for this working group.

Via header modification: comment = product-name "/" product version [tracecode [tracetime]]. Tracetime is the time when you last verified the object.

Purge operations: Trivial purge (ICP = RFC 2186: Internet Cache Protocol ), Decisive purge (HTTP). An ICP purge will not change the ICP version number. A new HTTP method "PURGE", which is being defined, must not be forwarded to origin server.

The PURGE operation does not delete a document, it only purges a copy of it from a cache.

There are obvious security threats, but these have not yet been discussed, and there is not yet any security-considerations text about this.

The URL will be removed from the ICP replies, by a new flag. If this flag is present, the flag is to be removed, and nothing returned (essentially a null object).

There is not yet any registry for new HTTP operations, so any group can define its own new HTTP operations without any control of what they are doing. But the IESG will of course not accept any new HTTP operations which conflict with existing standards.

Known problems of caching document

We have a problem template which you can use when you want to report a problem.

Problem areas: ICP, transparency, cache-control headers.

Problem: Cache meshes can break serialization of content.

Problem: Replica response time is unpredictable. ICP has scaling problems.

The working draft draft-wrec-known-prob-00.txt will be published soon.

Vendor protocols

WPAD (Web Proxy AutoDiscovery protocol) and WCCP (Web Cache Coordination Protocol) are vendor protocols.

Back to table of contents @ Other meeting notes

Content negotiation

This group is working on defining terminology and framework for agreeing on media types, not only to agree on a certain media type, like "GIF image" but also agree on its features, such as resolution.

Example of use: (1) You have a low bandwidth connection to a resource provider, but that provider has a high-band-width connection to the Internet (2) Limited devices like cell phones or palmtops and what web pages they can handle.

Also see my notes from this working group meetings at the previous IETF meeting, March 1999.

This working group has been going on for quite a long time now, so it is getting close to finishing its business. As is usual, the final discussions are often on small details, such as whether to use semicolons as separators, etc.

They will propose a registration procedure for new feature tags like color depth, screen resolution, etc. Parameters to mime types are not recommended.

Controversial issue: Should MIME Content-Type parameters be allowed, or should all feature tags be specified separately. This is related to the problem of combinations of sets of parameters, i.e. can you specify one charset for text/plain and another charset for application/pdf for the same document?

Are there problems with allowing different ways to say the same thing. For example explicit language-tags versus feature-tags on language. Controversial issue: References to very complex sets of feature tags. Example: The feature tags for Internet Explorer will be many pages, so you need some shorter variants. Should allow for comparison of two abbreviated feature tags without dereferencing them. Two alternatives: Using hash sum combined with URL, or only URL.

You should be able to specify such a feature tag set plus small deviations to it, like different color depth versus resolution.

Back to table of contents @ Other meeting notes

Process for the Organization of Internet Standards

This group is responsible for revising the rules of how IETF standards work is performed.

Issue: Can confidential information from previous years' nominating committees be carried over to the current committee. Answer: Yes.

Liaisons can participate as nonvoting members of the nominating committee, if appointed for this. There are two types of liaisons. (i) Those who you ask for advice. These do not participate in meetings, and should not be given confidential information from the deliberations of the nominating committee. (ii) Formal liaisons, which participate in meetings, and which are bound to confidentiality in the same way as for nominating committee members.

Fair and unbiased: The random method of selecting members of the nominating committee. A document on how to do this in a publicly verifiable way has been produced.

A method is fair if each eligible volunteer is equally likely to be selected. A method is unbiased if no one can influence its outcome. Eastlake, D., "Publicly Verifiable Nomcom Random Selection", Work in progress.

The rule for finding a chair for the nominating committee has been specified more clearly.

Some discretion (=power, influence) has been moved from the chair to the whole nominating committee.

Members of nominating committee are not eligible for positions during the full period of the nominating committee work.

What is happening with IANA when ICANN takes over?

IANA is the organization for registering port numbers, media types and other codes and IDs which need to be centrally assigned. ICANN will take over the registering of domain names, and also other IANA tasks.

PSO = Protocol Support Organizations: Will guide ICANN in performing the new IANA tasks. PSO is created by agreements between standards development organizations (SDO), and appoints 3 ICANN board members.

PSO can coordinate work done by different standards organizations.

PSO has very limited role on policies. It should more co-ordinate than decide, if a disagreement occurs, it should try to get the responsible SO to solve the problem rather than solve it for them.

It can review proposals from standards organizations (SOs) on new protocol numbers which need registration.

Status: ICANN has accepted PSO memorandum of understanding (MoU). SDOs have worked on a MoU. Participants in this work have been IETF, W3C, ITU and ETSI. Each SDO appoints two members to the PSO. SDOs can replace their representatives whenever they so want. Majority vote in PSO, 15 day notice for meetings. Quorum = half the members representing 3/4 of the SDOs.

Meetings will probably never be physical (face-to-face).

The Protocol Council (PO) will have a web site. The policy for a particular parameter to be registered is not in the PO but in the standards organization which required this parameter to be registered.

Suppose ITU and IETF disagreed on some new protocol parameter. Then it is not PO which decided, but PO can help ITU and IETF to resolve their differences by helping them talk to each other.

There was some discussion that one participant during the meeting thought that the new rules gave too much power to ICANN and the PC, but other people said this was not the intention.

PSO appoints 3 ICANN directors. These will be appointed as individual experts, not as PSO representatives.

The PC will host an annual open meeting (general assembly). Attendees will be expected to be SDO members.

All communication between ICANN & PC will be made public on the ICANN/PSO web site. All meetings will be reported there. In very special circumstances, certain private info can be kept secret for a delay time, but the hope is that such circumstances will never arise.

What must IETF do?

Specify a process to appoint its two PSO representatives.

Accept which SO should be members of the PSO.

The MoU may be signed during this ongoing IETF meeting.

Controversial issue during this IETF meeting: Should ETSI be a signatory or not to the MoU. (The other signatories, IETF, ITU and W3C, are not controversial.)

ITU and W3C will not have problems saying that they meet these criteria, but ETSI will have problems, Eric Huizer said.

What happens if IETF refuses to sign? The other three will sign without IETF. Is that what we want? someone in the audience asked.

Other solution: IETF, ITU and W3C sign now, and then the decision of accepting regional organizations, like ETSI, is done by the due process for accepting additional members of the PC.

This became a very heated discussion, with people strongly arguing for both alternatives. Arguments against ETSI: IETF should not accept any more dilution of its authority, attempts of ETSI to grab power over ICANN must be stopped. Arguments for ETSI: Otherwise IETF may be totally excluded from this important international co-operation, we should be open to accept many different solutions, developed by different organizations. The conclusion at the end of the meeting was that ETSI should be allowed in, but ETSI should be carefully watched to stop them from trying to grab power over the ICANN.

Back to table of contents @ Other meeting notes

Web Elucidation of
Internet Related Developments (WEIRD)

This was the smallest group only 14 people participated. This is the first meeting as a working group. The goal of the group is to develop a web site with information about IETF for people new to the IETF.

More info about this group: http://www.imc.org/ietf-weird

Mailing list: ietf-weird@imc.org

To subscribe: ietf-weird-request@imc.org

Chair: Chris Burke <Chris.Burke@motorola.com>

Discussion of possible URLs for the web site we are to set up:

Target audience: People now to the IETF and other Internet generalists

Content within scope:

• Current IETF WG and BOF activities
• Dependencies and interrelationships among specific IETF WG and BOF activities
• BOF historical information
• IAB/IESG/Secretariat issues
• Topics of interest and their impact
• Things hard to find on IETF site
• Things people would expect to find here

Home page layout: We would need help from a web designer. Should be simple, not overloaded with graphics, not more than 60 characters/line. Should have a site map to make navigation easier. Not necessarily by IETF area, perhaps do something new?

Work to do:

• Talk to Area directors, what they feel is needed
• Dynamically compiled searchable meta-standards archive (tag@datacaptureinstitute.com)
• IETF IQ Test to help people categorize themselves as new / experienced / etc. user
• Links to selected RFC/FYI documents
• Robert G. Ferell's page tabulation of Internet drafts
• Internet draft authoring hints (http:www.ietf.org/ID-nits.html)
• RFC Editor Queue
• Important page, difficult to find:
  http://www.rfc-editor.org/rfcsearch.html
• How does a document become a standard?
• RFC supplemental information, like links to graphics

What should our group not do, because it is already done by the RFC editors? We should use what is already available as much as possible, instead of rewriting existing informational overviews.

Should we track the number of hits, in order to know which are the most popular pages, which we should put more effort into improving.

It is important to distinguish between things we have to do once, and things we have to maintain. For the latter type, we must arrange for a procedure to ensure that these pages are maintained.

Content inventory:

• IETF AREA overviews
• Q&D links to existing info
• FAQ "IETF stuff"
• Hot Topics (IPV6, IP Telephony)
• Upcoming BOFs
• Which documents you have to understand before understanding other documents. Risk: This might be an endless chain of going back and going back.
• RFC supplementary info, graphics, etc.

Back to table of contents @ Other meeting notes

General assembly meeting for everyone

This is the first IETF meeting where 3 different wireless IP services were available. And the terminal rooms did offer IPV6. 36 people did use IPV6, 100 more had IPV6 in their laptops but did not use it.

An ITU (International Telecommunications Union) representative made a presentation of ITU-T work. ITU is a much older standards organization than IETF, it was established already almost 150 years ago. Today, ITU-T is more and more developing standards in the IP area. In particular, ITU-T is presently working on many IP standards, in particular signaling and mobile phone IP, but also many of the other IP standards areas. Whether this means that we will in the future have two conflicting versions of standards, one of them made by IETF and one of them made by IETF, I am not sure. If, however, ITU is going to make its own, slightly revised version of IETF standards, one should note that IETF also sometimes takes standards made by other organizations, and makes its own, modified versions of them. Example: RFC 1766 (tags for the identification of languages) which is based on, but extends, an ISO standard.

Back to table of contents @ Other meeting notes

IMAP Extensions

IMAP is an advanced protocol for downloading mail and managing remote mailboxes. It is an old standard, and has been updated several times, and this was a session for yet another round of updates to IMAP.

13 people had read the drafts, an additional of 23 people listened in the back rows.

Agenda:

• Charter
• View/Sort/Thread
• ACL
• Annotations
• ID
• Language
• VPIM
• New issues (child mailboxes)

View/Sort/Thread

A new command VIEW SET.

Example: VIEW SET SEARCH FROM CYRUS

This command will return an ID for the found, sorted set, to use in further IMAP commands.

It is possible to access individual messages in such a set by ordinal number in the set, or several messages by specifying a range.

Clients can be notified of new arriving messages within the view. This is a controversial issue, it causes possible problems with other IMAP commands.

All responses will return both the ordinary sequence number and the vie ordinal number.

Possible alternative solution: Extend the SELECT command. Both alternatives will be investigated.

Issue: Allow multiple, named views. No decision, a few participant wanted to implement it, other thought this would make IMAP unnecessarily complex. (Note: A user can always open multiple connections in order to get multiple views, but this is not without its problems.)

User requirements on dynamic views: New messages should be added, but messages should maybe not drop out of a view during its lifetime. This mode could be labeled hybrid, and would be a third kind of view. Developers may have difficulties implementing this. Discussion on how clients can request dynamic versus static views, and how the server might asynchronously notify the client of new items in a view.

Sort: Create a new sort2 extension with some new sort facilities, and which can work together with the view extension. Problem: Additional sort keys will break old SORT implementations, so this must be a new extension.

Threading: If implemented, should be clearly separated from VIEW and SORT. THREAD would be supplanted by extended command THREAD2.

Access Control Lists (ACLs)

(i) Problematic when mapped on the UNIX file system. (ii) An identifier namespace for groups is needed.

Annotations

The ANNOTATE extensions allows users to add metadata to messages and specific parts within a message, and allow the client to retrieve the metadata. Would be implemented with some kind of attribute/value model.

Requires modification to the FETCH command to get a message with a certain annotation, and to store annotations on messages. Searching and sorting on annotations is also needed. Can every single annotation have its own ACL?

Language

Should maybe not be implemented unless a more comprehensive internationalization strategy is adopted. There are some servers and clients who have implemented language, and this might be documented in a nonstandard or historic standard RFC. There are also issues of sorting and searching. And maybe translation issues too, ask for a message translated to a particular language.

VPIM

Extensions to IMAP to support voice profile. Voice profile has a separate IETF working group, but the work of combining VPIM with IMAP does not have a working group yet. Requirements: BINARY attachments in addition to BASE64 (yes), optional TO keyword in DATA (no), new DECODE command to select CODEC format, STREAM part specifier for streaming audio in FETCH, message length indicator, separate "seen" properties for every body part.

John Klensin was critical of making special extensions for special media types, but several other people said that some of these extensions are of general interest and are not limited to the voice media type.

Back to table of contents @ Other meeting notes

Instant Messaging and Presence Protocol

Summary

The main disagreements seems to be based on two groups: People who want to make a simple, restricted service for Instant Messaging and Presence, and people who say that this is too restricted and does not work well together with the rest of Internet services.

There was a lot of discussion about what is meant by requirements, whether requirements should be ordinary human users' requirements, or also technical requirements. For example, Message-ID is a technical solution, but not a user need.

IETF has generally not been very good at understanding user needs, it has been dominated by engineers thinking in technical, more than user, terms.

Model

Presence Service: Presentity sends presence info, Watcher gets the presence info. Updated presence information is sent as notifications to those subscribers who want these kinds of presence notifications. Subscriber is one kind of watcher, fetcher is another kind of watcher, a poller is someone who regularly asks for presence info.

Instant Messaging Service: Sender sends an instant message, it is forwarded to particular instant inboxes. Important difference is that the instant messaging service does not store the instant messages, as it does with the presence information.

Requirements issues

• One protocol or two?
• A single NAMESPACE (for both presence and instant messaging)
• Enumerate minimum STATUS codes? (currently: OPEN/CLOSED and available/busy/idle. Open means that you can accept instant messages, closed that you can not) (This caused a long discussion. People wanted an open-ended, extensible set of status codes, with a minimal mandatory basis. And you can be separately open and closed for different kinds of instant messages.)
• Are Message-ID's to be required?
• IM delivery failure: the service MUST notify sender? or SHOULD notify sender?
• Use SMTP for IM transport?

One protocol or two?

Are presence and instant messaging so different that they should have different protocols?

Advantages with one protocol: Completeness, shared namespace and facilities.

Advantage with two protocols: Cleaner decompsitions, allow separable implementation of only one of the two services.

IM could be used as a transport for Presence, by special kinds of instant messages.

Even if we choose different protocols, we should define how they can work together, because that is what the market needs.

Someone said: Once you have Presence, you may want other facilities than IM, for example shared web pages, voice conference, etc.

Someone said: Requirements should start with user needs. Issues like common protocol or common namespace are technical requirements, and you should first specify the user requirements.

Someone said: This is different from other directory lookup services, in that you may want to ask a person for permission to divulge his location to someone else.

Keith Moore said that we should look at what RESCAP (Resource Capability Discovery) is doing.

Issue: Presence-centric or IM-centric model? Should people first have to have a Presence-service subscription before sending IMs, or the reverse.