IETF logo

Applications IETF November 1999 Notes

Personal notes from some applications area sessions during
the IETF meeting in Washington D.C., November 1999

By Professor Jacob Palme,
Stockholm University and KTH Technical University

Abstract

  Here are my personal notes from the IETF meeting in Washington D.C., November 1999. Opinions and statements in these notes are not mainly my own, but rather quotes of things I heard people say during the meeting, even when I do not use quote symbols or specify the name of the person being quoted. The selection of what to report is based on my personal interests from some of the meetings in the applications area. In some cases, what I quote below are statements, which sounded interesting to me, but not always statements I understood fully.  

Table of contents

   

General Introduction

 

All the lecture rooms had wireless transmitters placed around the rooms, and people could buy or borrow wireless PCMIA cards. Only for Windows computers, not for Macintosh or Unix.

Traditionally IETF standards work is done on mailing lists and on these three-times-a-year big IETF general meetings. But it is becoming more common to have smaller, interim meetings where a group could discuss its issues for a couple of days and not only the restricted 2-3 hours which they can get at IETF general meetings.


Applications Area General Meeting

 

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

There is lots of things happending in the applications area, lots of documents waiting for action by the area directors or the authors, lots of working groups.

BOFs this time

BOFs are meeting with groups which have not yet been formed as IETF working groups. They are sometimes new ideas for possible new standardization. All of them do not get into standards development stage.

Some of the BOFs at this meeting were:

VPIM

Voice profile over Internet mail.

QUALDOCS

Extending the IETF fax protocols for more general document interchange applications.

IPPEXT

The Internet printing protocol is almost ready, there is some finalization and some new issues to discuss.

RESCAP

Resource capabilities directory.

IDNS

Internationalization of the domain name system. How can the domain system cater for domain names in languages like Chinese or Russian? An important and difficult issue.

ECML

Electronic Commerce Modelling Language.

MMMS

Mobile Multimedia Messaging System.

IMAPEXT

Extensions of the IMAP standard for advanced remote control of mailboxes on servers.

WHOIS EXTENSIONS

Extending WHOIS to better handle world-wide searches and other extensions.

Back to table of contents @ Other meeting notes


NNTP Extensions group

 

About 20 people in a room with seats for about 200 people. Probably because this work has been going on for a long time, and there are only small technical details left.

RFC977bis issues

RFC977bis had confusion about where you can put an exclamation point in the Wildmat protocol.

Security Considerations: More should be added about the risks caused by DNS spoofing. To counter this, you should make a reverse lookup and a forward lookup and check that they match. It is not 100% secure, but it makes spoofing much more difficult, the spoofer may have to hack into two different DNS servers, and a spoofer may have access to only one of the two servers.

Response code issue: Is 435 a valid response to give after an article has been presented, but the receiver does not want to see it again, or is 437 a better choice? Group agreed on 437, which is a change to the current drafts.

PAT has a generic 502 response. Important: We should not give any significance to the text after the response code. If we need to distinguish, we should invent differentiated numeric response codes.

There is a problem with the time format in the NEWNEWS and NEWGROUPS commands. Should the UTC time format be allowed? There is a problem, because existing implementations use different time formats. The present standard says that GMT is allowed in two cases, but UTC in only one case. Someone argued to restrict the standard to only one format (GMT) to makes things simpler instead of more complex.

Authentication (NNTP-AUTH document)

Without the "list" extensions, authentication will not work, so the standard should specify that those using authentication must also implement the list extensions.

More info:

ftp://ftp.academ.com/pub/nntp/ietf

Back to table of contents @ Other meeting notes

 

Instant Messaging and Presence Protocol

 

This is the group for making standards for systems like ICQ, which allows people to know which of their friends are on-line, and to send short rapid messages to these friends.

Popular issue: This is a very popular issue, about 150-200 people were present, there was lots of discussion with different opinions and difficulties understanding each other and reaching agreement. Sometimes long queues in front of the discussion microphone. Everyone seemed to have their own idea of how IMPP is to work and what you are to be allowed to do using IMPP!

Wireless: A current topic in this group is whether to support wireless communication. Patrick Fältström said that the group should produce Internet protocols, and these protocols should then work across all IP connections, even wireless connections. However, the group might want to make the protocol efficient, so that it will work also across thin connections.

Existing documents: The present documents on model and terminology will become informational RFCs, not IETF standards.

Standards to be produced:

  • Service Integration (SI)
  • Presence Information Data Format (PIDF)
  • Message Information Data Format (MIDF)
  • Presence Information Transfer Protocol (PITP)
  • Message Information Transfer Protocol (MITP)
  • Maybe an informational document, too?

General protocol: A general protocol for all kinds of instant messaging, or a more restricted protocol for typical Internet presence applications.

Servers: Must the protocol support multiple inter-working servers? Most people seemed to think so. What is the difference between the client-server and the server-server protocol? The protocol for talking to clients must accommodate low-capacity clients on slow connections.

ISP Role: These protocols should not be restricted so that you can only use the presence server provided by your ISP (Internet Service Provider). An ISP monopoly on providing precense services may not be in the users' interests.

Security: A very controversial issue. It is common in IETF standards to say that "security will be added later" and then never coming up with agreed security standards. At this meeting, the disagreement was between people who wanted fully specified security from the beginning, and people who wanted a security framework, but with details to be filled in later. A number of very influentical IETF oldsters said that security is absolutely essential, and that proposals without security are worthless. Security is not only "security considerations" but also "security design". The IESG will probably not accept a proposed standard without security support in it.

Securit includes Data security (integrity, authentication, encryption), ACL (Access Control List) requirements and Firewall issues.

Data security: Public key digital signature is better in distributed systems, but slow. Keyed MAC is fast, but requires a shared secret in advance. A hybrid system is recommended, using public keys to exchange the symmetric keys.

Authentication should be done using public keys. Someone among those present said that this requires public key infrastructures, and such usally are not very successful.

Transfer encryption could be in the transport layer, encryption of messages or a hybrid solution. Encryption of messages is recommended, because transport layer solutions are less flexible, and hybrid solutions are too complex to implement.

Draft: draft-sugano-impp-security-00.txt.

Someone in the audience: There are many other useful security techniques which you have omitted to mention in your proposal.

Trust issues: Who trusts whom? Sometimes a message is transported between a client and another client, without the intervening server being allowed to read the messages in transit.

Intermediate meeting has been held in San Francisco

Agreements at that meeting:

  • TCP as substrate.
  • Use extended e-mail-style naming.
     (Something like RFC 2302: Minimal PSTN address format in Internet Mail
        Example: FAX=+1.202.7653000/T33S=6377@faxserv.org). 
  • Simple XML format for presence format.
  • Presence as MIME object, contention on the exact tag.
  • RFC-822 style as basis for IM format.

Discussion: Will wireless in the future be as unreliable and expensive as today? This was controversial and got lots of discussion! Real INTERNET solution various restricted WAP stacks?

Back to table of contents @ Other meeting notes

 

Web Versioning and Configuration Management

 

More info: http://www.webdav.org

This is an outbreak from the WWW Distributed Authoring and Versioning group (WEBDAV). I did not have time to go to that group's main meeting. The WEBDAV group has created a standard to support a distributed group of people who develop documents or sets of documents together. It includes facilities for downloading and uploading documents, and marking them to handle simultaneous documents. Documents can be stored in a hierarchical structure of collections. Documents can be for example HTML documents, Applets, Server-side scripts, etc.

It is actually more than a document storage, the objects you can store and retrieve are general-purpose objects and you can easily add new object types with new kinds of attributes. Attributes are described using XML.

In the meeting which I was not able to go to, they were discussing ways of putting links from documents in different places of the tree structures of collections. They were also discussing methods of putting an ordering on the resources in a collection, either a user-supplied ordering, or an ordering done automatically by the server according to some ordering rules.

The present meeting is about versioning. If two people check out the same document, revise them, and check the revisions in without merging their revisions, then two branches are created in the versioning tree structure.

Facilities:

  • Create a resoure,
  • update it,
  • make it a versioned resource,
  • track its history.

WEBDAV uses PUT and GET methods (=HTTP commands) to put and get documents. A new method VERSION will make a document into a versioned resource. Another new method MKRESOURCE will create a workspace to store revisions. Every user who simultaneously update the same document will give it a workspace label used in storage and access. The workspace label will make it easier for a user to retrieve a particular version. You can also ask for the "latest" version, but that can be dangerous, if several people check in different versions, you are not sure which version you will get if you ask for the "latest" version.

When you do a CHECKOUT, you can use a Target-Selector to indicate which workspace (=version) you want to retrieve.

A revision can have multiple revision-labels, but no two resources can have the same revision-label.

You can find predecessors, sucessors, and revision history of resources. You can add and remove labels from already stored resources.

Back to table of contents @ Other meeting notes

 

Open Plenary for all Participants

 

Introduction

Total number of participants: 2300. U.S. percentage is going down, Japanese percentage is going up.

The Internet Society was started, said Fred Baker, because otherwise the directors of the IETF would be personally liable for decisions made by the IETF.

Update on the Trademark Trademark Dispute

A presentation by Robert Kahn, CNRI and Donald Heath, ISOC.

A company called "Internetting" had requested a trademark.

Internet, Inc. (II, also known as Star Systems) filed TM applications with the PTO in 1988-1989. In 1994, CNRI and ISOC jointly petitioned to cancel the registration of Internet for the term "Internet". They wanted the term to be freely available for anyone who neded to refer to it. IN 1991, CNRI for ISOC filed for a trandemark on "Internet society".IT said sorry no, you should stop using the term Internet. The PTO had a backlog of about 1000 different applications on names containing Internet in it. PTO position is that the term Internet is generic, but in spite of that they did not allow any application to use this workd in descriptions. CNRI, ISOC and II agreed to settle the dispute by taking the term Internet off the registry, making it freely available to anyone for use as a generic term. Final action by the PTO has not yet been taken.

Top N Miscoceptions about Web Traffic that Internet Implementors should Know

HTTP is the dominant protocol on the Internet. HTTP/0.9 and HTTP/1.0 were never formally standardized.

There are many widely known sites which are not yet running HTTP/1.1, for example Yahoo. Study: What features of HTTP/1.1 are people really using?

Data was collected from 800 representative web sites.

  1. We checked support for the MUST features of HTTP/1.1, GET, HEAD, Host header.
  2. Important feature additions in HTTP/1.1 like persistent connections, pipelining, range-requests.

Server statistics: Netscape, Microsoft on top.

GET is supported by 80 %, HEAD by 70 %, Host by 64 %, POST by about 60 %.

Absence of HOST header: 1.1 % of clients did not send it, 7 % of servers accepted this.

Category 3 unconditional compliance: OPTIONS 60 %.

Security, DOS, and other problems: Some servers od not properly handle too large requests. Devices terminating connections should identify themselves, but this is not always done.

Sites moving to HTTP/1.1 do not always do it in compliant ways.

What happended after publication: We were threatended by lawsuits, got nastygrams. The DOS attack was fixed in major servers.

Why care?

Web is 72 % of flows, 55 % of packets, 56 % of bytes.

6-8 % of connections are aborted by abort command or click ahead.

Web sessions have a poisson distribution, but TCP connections and Packets are bursty.

Reuse of connections (persistent connections) is increasing, and this will reduce the burstiness of connection arrivals, but not of packet arrivals.

If you have a large number of small transfers, then the TCP connection set up time is signifcant and TCP connections stay slow in their start. They also introduce burstiness.

A small number of large transfers carry many bytes. Dynamics is driven by "background" traffic.

Web and DNS

Server reverse lookup is done for logging, authentification and targeted advertisement.

Load balancing is needed for DNS servers.

DNS lookup is a large portion of the delay experienced by users. DNS cache misses are increasing.

Cache can be near the client, in the middle or near server. This gives very different effects.

http://www.w3.org/WCA/
http://www.w3.org/1999/05/WCA-terms/

Healthcare on the Internet

Report not yet published, recommendations not final. Details on www.nas.edu. (NAS= National Academy of Science.)

Goals: To influence government, public policy and the research community.

Comittee: Many medical doctors, also some computer scientists.

Internet today fails many healthcare needs: unacceptable QOS (Quality of Service), unacceptable limits on security, unacceptable reliability, ubiquity of high-speed access.

Because of this, private networks are heavily used. But private networks are expensive, require large investment in manpower and equiplment. Private networks do not well support dynmaic creation of relationships and the decentralized nature of helathcare.

Do we really require to move a mammogram in 2 seconds, or is 15 minutes OK?

Healthcare has very variable requirements. But so has other users.

Bad security is very costly, maybe more than in other network uses?

A working Public Key Infrastructure would be very valuable to health care uses - Why does it not occur today?

Ubiquity is a hot area, especially for rural areas who do not get as good Internet service (for example DSL will not work, maybe not even ISDN).

The healthcare community could benefit a lot from Internet community, but they are not using it much today. Other industries, not health care, are setting the priorities for networks. Healthcare is a late adopter. We hope more medical informatics people will participate in IETF work.

Healthcare agencies might be more willing to fund research grants in the healthcare informatics and networking area.

Should IETF Standards Support Wiretapping?

Should the IETF support protocol features whose use is specific to wirtetapping?

IPV64 was not designed for wiretapping. Traditional voice networks tend to support wiretapping, Internet traditionally has not. Question: Should the IETF support protocol features whose use is specific to wiretapping? (Many functions meant for other uses can also be used for wiretapping, even though they were not made for that. It is not reasonable to exclude a useful functions just because they might be used for wiretapping.)

The IESG discussed this, and found that this was a metaquestion, not to be decided by an individual working group. Instead, a mailing list (called RAVEN) was set up to try to get a sense of the community views. It has 453 members and 266 messages. Of people who stated their views in RAVEN, 2/3 were opposed to wiretapping, 1/3 abstained, only a few people favored wiretapping.

Those who are in favor in RAVEN: "The IETF can ensure it is auditable", "We have to do it, let's do it in the IETF".

Opponents in RAVEN: "Over my dead body", "Violates my human rights", "Weakens security" (can be misused by hackers).

The face-to-face discussion was very emotiona, with applause for everyone who spoke against wiretapping:

  • "Let them do their dirty work, but do not help them."
    "What is meant by 'legal' wiretapping?".
  • "Wiretapping cannot be made secure and will make protocols much more complex. It can be done wrong in many ways."
  • "How it started: the FBI went after our own, we reacted."
  • "Meaningless set up a working group on wiretapping, we would never be able to get any consensus conclusions in such a group."
  • "Our moral ground is not as high as we like to think it is, since we have invented various features which makes wiretapping easy."
  • "It is easy to do the tap, it is hard to restrict what the tap can do."
  • "There is no legal requirement on us to put wiretapping into the protocols (in the U.S, may be different in other countries.)"
  • "The telephone industri went through this, they tried to desist, but did not succeed in doing this."
  • "You have to explain to people the risks entailed with making protocol features for wiretapping."
  • "This cannot be done right and we do not need to do it."
  • "Define the protocols to make it difficult to add wiretapping in the future."
  • "Laws are different in different countries, for example in Sweden it is illegal to mention a person's name in an email without permisson from that person - difficult to specify wiretapping protocols to be right according to the law in different countries."
     (My Comment: It is true that we have such a law in Sweden, but no one has been prosecuted for not adhering to this law.) 
  • "The core issue is if people are being wiretapped, how many, how often. Today it is difficult, timeconsuming, expensive, and that restricts the amount of wiretapping. If we made wiretapping effortless and trivial for governments, we would risk getting much more use of wiretapping."
  • "Are you going to make it possible for anybody to do wiretapping? Should we enable every intelligent high school student to be able to do wiretapping?"
  • "The law enforcement community is forcing us to make unreliable networks".
  • "It is not the task of IETF to design protocols to the needs of every law in every different country."
  • "What is going on outside the U.S.? ETSI in Europe has done a lot of work in this area. ANSI has started to raise the issue in international standards activities."
  • "All future Internet protocols should not be mandated to contain a wireapping feature. Do not overreact, you do not have to answer every question put in front of you."
  • "Some people said 'if we cannot do this right, we should not do it.' Well, thinking about what we have done in other protocol design issues..." (laughter)
  • "Equipment is more and more moved to the ends of the networks, into people's homes, and end-to-end encrypted communication cannot be wiretapped in the middle."
  • "This discussion is fundamentally silly, since wiretapping is the same as conference calls, and we have to design features to support conference calls." (no applause)
  • "In the U.S. a wiretap must be approved by a judge, and you have to show probable cause."

Question: Do we want the IETF to support special protocol features whose sole use is for wiretapping, which the user is not told about.

Show of hands: Less than 10 % yes, About 10 % abstain, About 80 % no.

Alternative question: Should we implement features to make it easy for people to find out if they are wiretapped? Should we design features that disable wiretapping? About 50 % yes, About 50 % abstain.

See also an article in Wired.

Back to table of contents @ Other meeting notes

 

LDAP Extensions

 

More info: ftp://ftp.innosoft.com/ietf-ldapext/archive.txt

Current issues:

  • Virtual list view/Duplicate entries
  • C API and Java API
  • Access control model
  • Server Location
  • Referrals
  • CLDAPS
  • LDAP error codes
  • Dereferencing match
  • Extended partial response
  • Password policies

Back to table of contents @ Other meeting notes

 

Electronic Commerce Modelling Language BOF

 

Web site: http://www.ecml.org

The object of ECML (Electronic Commerce Modelling Language) is to specify a standardized set of common fields, so that when a user connects to a merchant web site, most of the form fields can be filled in automatically. It is not a big standard, it is a small, simple, light-weight standard. Many existing merchant sites can be converted to ECML in perhaps an hour work.

It is not a payment system, but credit card number is one of the fields which can be specified for automatic filling in. ECML does not itself provide any particular security, but can be used within some security system.

ECML Alliance Steering Committee: American Express, AOL, Compaq, CyberCash, FSTC, IBM, Mastercard, Microsoft, SET Co, Sun, Transactor, Trintech, Visa.

ECML version 1.0 can be found in RFC 2706 "ECML V1 Field Names for E-Commerce".

Future work: Internationalization.

Three working groups: (1) Marketing, (2) Version 1.1 and (3) Standards Transition. By Standards Transition means transfer of responsibility to an established standards body, such as IETF.

Membership in the EC alliance is open, currently 85 organizations are accepted or in process for acceptance.

Question: Why IETF and not W3C? Answer: The protocol is not limited to web, and we believe IETF is a better standards organisation. You can participate without having to pay W3C membership dues. The interoperability testing which IETF requires is important.

Technical futures: Mercant ID, shipping tracking info, cost, payment through cards requiring PINs, ACH, eCHECK, etc, Multi-currency capabilities, Privacy mechanisms. Frequent flyer points and other customer loyalty programs, business-to-business connections.

The customer can tell the merchant which payment systems this customer supports.

ECML specifies certain fields. If you use these fields, you must give them the ECML names and use them in the ECML specified way.

 

Mobile Multimedia Messaging Service BOF

 

Mailing list: ietf-mmms@imc.org

Write to ietf-mmms-request@imc.org with "subscribe" in the body.

There was a long and very wide-roaming discussion where all kinds of different ideas were put forward by different people, as quoted below. I have reorganized the statements in sections for different topics, and do not quote them below in the order they were presented at the meeting, where all was mixed together.

Use existing e-mail protocols?

Question: Why not use existing systems, like e-mail?

Two alternatives:

  1. Adapt existing short message services for mobile usage to multi-media.
  2. Adapt MIME standard to mobile usage.

Most people seemed to favor the second approach.

We should avoding inventing still another messaging standard in addition to existing messaging standards.

Should we redo Internet e-mail.

Not define new protocols, but develop a specification of profiles on how existing protocols can be used for wireless multi-media messaging. Then we may find out where existing protocols are not enough, and where new protocols need to be developed.

Bandwidth issue

Several people pointed out that future wireless communication will typically provide 64 kbit/s, which is more than many people using modems to connect to the Internet today have. So the issue is perhaps more the handling of small screens than the handling of low bandwidth.

The important problem is not speed but cost. Cellular networks typially cost 10-20 times as much per packet as physical line media like copper wires or fiber. The reason for this is the limited size of the wireles spektrum. So cellular protocols must be very much oriented towards small, simple format, not for speed reasons but for cost reasons. Someone else said that wireless developers are developing new solutions to avoid this problem and have multi-megabyte/second wireless communication at reasonable cost. (The person did not say how this works. Smaller cells?)

WAP versus IP

WAP is not compatible with HTML, but work is going on to merge WAP with XHTML (HTML combined with XML).

One person said: Streaming should be accomodated (to allow you to hear the beginning of a sound message before it is ended. I do not think the person meant simultaneous streaming for same-time communication between sender and recipient.)

What is the relation of what we try to do with WAP?

Use of POP or IMAP or SMS?

SMS is more push-oriented, while POP and IMAP are more pull-oriented. POP and IMAP put too much of a burden on the client in wireless applications.

Issue: Do IMAP all the way to the client or not. Are present e-mail protocols to chatty and too much requiring fast turn-around time, to be suitable for wireless networks?

IMAP may have problems because of its connection-orientation.

Patrick F said: I have been working with gatewaying e-mail to SMS for several years. It is hard, really hard. X400 gatewaying is simple in comparison.

Miscellaneous issues

WAP has something called "service indication" which is a small, simple notification from a server to the client of events of interest to this client.

Geographical position issue, position privacy issue, position metadata issue. W3C and the Web Forum is going to organize a workshop on this in Nice, France in February, 2000. Someone else said that the Internet infrastructure has nothing to do with position information.

Conclusions

First steps: Identify what we want to do, and what requirements it has. Do not specify architecture or solve technical problems before you have identified the needs more clearly.

Choices:
  1. IP exists at a speed of 10-20 kbit/seconds. How can existing Internet protocols be downsized to smaller screens, smaller hand-held mobile devices?
  2. Can SMS (no interactivity) be extended? Note that SMS allows you to push things onto a device! Not the same was web push. Can SMS be integrated with the SMS-NG world? No, you cannot integrate, only gateway!
  3. Do we want to run MIME on top of something else than IP? Is running things on top of other than IP out of scope for an IETF group?
 

Common Name Resolution Protocol BOF

 

The object of this work is to make it possible to easily find an object given its "common name". By common name is a short human-friendly name without specified internal structure. Example: "Yellow Cab", "Hitachi", "Holiday Inn", "United Nations", "Madonna". This is not the same as a search engine, which finds web pages about a certain object. Many search engines have, however, started offering these kinds of services, for example the "Real name" service.

This group intends to develop a standard for accessing such data bases. Since often, more than one object may have the same common name, there will be a way to restrict thesearch to categories and areas (example search for "Yellow Cab" in "Boston" or search for "Madonna, the artist"). Language may also be useful as a restrictor, but should be a list of preferred languages in preference order.

For more information about the basic issues, see my notes from previous IETF meetings in March 1999 and December 1998.

The matching can be exact, partial or possibly even fuzzy. Fuzzy matching was a very controversial issue. Should you allow misspellings, phonetic matches, should you in the German language match "Müller" and "Mueller"? The main agreement seemed to be to allow fuzzy matching but not specify how it is done.

The schema for specifying a user's preferences may be rather difficult to specify.

Can servers refer to each other? If so, should the returned results tell the user from which server a particular answer came from? What about the high cost of referrals to many servers? Should the user be able to control the cost?

Protocol base choices:

  1. HTTP for simplicity
  2. LDAP to fit existing directory services
  3. UDP for performance, etc.

The WG will start by specifying an HTTP-based protocol.

This working group may reduce the domain naming system problems, with every company competing for "their" name in a domain name. And it may support non-English names, which is a problem in the DNS if non-English characters are used.

 

Whois Extensions BOF

 

ftp://ftp.ietf.org/internet-drafts/draft-faltstrom-whois-04.txt

The Whois world is split into many separate local whois servers, which are not connected, and people have no good way of finding which server has the data you are looking for.

  • Establish a central registry of whois servers.
  • Define the format for specific functions:
    • Version number.
    • Character set (Untagged, many servers mix character sets without information. Sometimes you can guess the character set.)
    • Automatic referrals.

Version number should be sent before any new commands, and charset should be sent be sent before any data in other character sets than US-ASCII.

Central Registry

Possible formats:

  1. Attribute/value pairs
    (disadvantage: Only flat list)
  2. s-expressions
  3. Bind/gated settings
  4. XML

It should be possible to build proxy whois servers. Client connects to proxy, proxy finds the right server from the IANA registry, and then connects to the right whois server to get the data.

Advantage: User can use an ordinary whois client, which does not know about the extensions. All the knowledge about the extensions can be handled by the proxy, the IANA registry and by some existing whois servers.

TLD = Top Level Domain. In the contract when you get a TLD should be that you should register, with IANA, where the whois server is for this TLD.

Copyright

Someone proposed a new "copyright" command in whois. This led to a discussion of all kinds of "legal" fields which lawyers may want, and whether it is enough to store the URL of the legal text, or you need contain the whole legal text in the protocol to make the lawyers happy.

Perhaps this would be needed in other standards. But generally, IETF shies away from all kinds of legal information in standards.

Character set

Problem: What happens if different servers use different character sets. What should the proxy do when it collects data from several servers with different character sets. If the proxy can only have one character set, it would need to convert, but general experience is that you should not convert character sets, or if you do, do it as late as possible (i.e. in the client, not in the server).
 

  Back to table of contents @ Other meeting notes