| |
By Professor Jacob Palme,
Stockholm University and KTH
Technical University
E-mail: jpalme@dsv.su.se
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:
- Unusually many new ideas, which
have not yet been approved, or
- Meetings in areas where people
have not established any IETF working group
- because of problems fulfilling
IETF requirements, or
- because of the speed at which
results are needed (IETF working groups often mean slower standards development),
or
- 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 www.apps.ietf.org/last-calls.html.
Mailing list for general issues in the IETF applications area:
discuss[-request]@apps.ietf.org
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: http://blackhole.vip.att.net/wwwseeker/
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: findstuff[-request]@lists.internic.net
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 http://www.cs.caltech.edu/~adam/isen/ 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
|
|
|
|
| |
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 http://www.ics.uci.edu/~ietfswap/index.html.
Back
to table of contents
|
|
|
|
| |
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:
- 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
- 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:
HTTP-NG Architectural
Model (draft-frystyk-httpng-arch-00.txt), Internet Draft, August 1, 1998
HTTP-NG Web Interfaces (draft-larner-nginterfaces-00.txt), Internet Draft, August 1, 1998
HTTP-NG Binary Wire Protocol (draft-janssen-httpng-wire-00.txt), Internet Draft, August 1, 1998
WebMUX Protocol Specification (draft-gettys-webmux-00.txt), Internet Draft, August 1, 1998
Design of HTTP-ng Testbed, W3C Note (http://www.w3.org/TR/NOTE-HTTP-NG-testbed), 10 July 1998
Short- and Long-Term Goals for the HTTP-NG Project, W3C Note, (http://www.w3.org/TR/1998/WD-HTTP-NG-goals), 27 March 1998
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:
ietf-trade@lists.elistxt.com
Archives: htttp://www.elistx.com/archives/ietf-trade
Web site: www.otp.org
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.
OBI:
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 <johnny-auto@foo.bar.net> (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!
- Documents:
- Replacement for RFC822
Replacement for SMTP
Back
to table of contents
|
|
Short
Mail-Related Extensions Proposals
|
| |
Anti-spamming
(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
|
|
|
|
| |
(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:
draft-calhoun-diameter-res-mgmt-02.txt
draft-greene-ss7-session-setup-00.txt
draft-taylor-ipdc-00.txt
draft-pickett-ipdc-managment-00.txt
draft-dugan-ipdc-connection-00.txt
Framework: draft-greene-ss7-arch-frame-01.txt
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
|
|